How do you Sprint?
-
How long are your sprints? Do you do a week, 2 weeks or a month? Or something else?
Does every area of your IT departments follow the same sprint duration?
Why I ask is that recently we have been asked to move to a 2 week sprint. I'm in the data warehouse area and we have been used to doing monthly sprints. I can see how a 2 week sprint is beneficial to application developers, but I think it's not a one size fits all approach. I know that where I used to work we tried the 2 week sprint and after a while we went back to a monthly sprint. And the same thing at my current employer. Several years ago we started with the 2 week sprint and determined that that didn't really fit with the work we do on the data warehouse team. We tend to have larger tasks that extend longer then 2 weeks.
This leads me to my next question. What do you use for your 'ticket' or 'work' management? We are using JIRA. We have been using it for a long time and I think it works really well.
How do you estimate your work for these tickets? Do you use hours or a point system? We are also switching from hours to a point system.
Now that we are on a 2 week sprint we are being asked to break down our tasks into multiple tickets. The intent is that what we take on in a sprint is closed by the end of the sprint.
To me this just seems to be creating more work for ever task we take on. For the bigger task I will now have one ticket just to research the ticket. Another ticket for my coding and testing. Then maybe another ticket for user testing. Another ticket to assign to a coworker to do the code review. And yet another ticket for moving the changes to production. So instead of having one ticket for the whole task, I will now have 4 or 5. Jira is easy to add links to each of the other tickets so you can easily jump around as needed. But it just seems like a lot of extra work.
I guess I always like the KISS method or the saying 'work smarter, not harder'.
Let me know if I'm just being resistant to change or if you think it seems like overkill.
And yes this change has been initiated from our new CIO, who came from within the organization, but came from an application development area, where again I think this would work well for them.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. -
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
-
As I stated above we were told we had to complete each ticket by the end of the sprint. But at the meeting to close out the last sprint we were told if it has to carry over it's OK. How frustrating that we change the rules after the fact.
To start the next sprint I wanted to at least add a few more tasks thinking that if I don't get to them we can move them to the next sprint. But I was told a report will go to upper management of what we initially take on, and it would look bad if we had to move some to the next sprint. Again mixed messages to me.
And we were told if it's getting near the end of a sprint and you need work, just start on a task in the backlog or next sprint, but DON'T move it to the current sprint. Because of needing to close out everything at the end of the sprint. I want to say WTF, you just let some carry some tasks from the prior sprint to this one.
You know, it helps to at least type this out and get it off my chest. 😉
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. -
I feel your pain. This is micromanagement at its worst. Personally, I won't row to the sound of a beating drum, the cadence of which has been created by people that don't know what a symphony is capable of.
I know how talented you are... I'd spend some time with a good recruiter or two.
As a bit of a sidebar on the latter, make sure that you're not "jumping from fat to fire". I got badly burned by that once. The company that hired me lied out their teeth. "Must look eye".
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Micromanagement is exactly it. I just kept looking at it from the my point of view in that 'you keep putting road blocks in my way'. I guarantee the amount of work getting done after this change will be a lot less than before. Oh, the number of 'tickets' we do will skyrocket up, but the amount of actual work will be less.
I'm not looking to leave, other than this I got a sweet set up right now. Work from home, no nightly on call and my main responsibility at month end takes me 3 to 5 days. Most of that time is dealing with bad data from outside vendors.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. -
I'm the same way. I've been at the same place coming up on 12 years. Great people, interesting work, good pay and bennies, a commute that I could make on a uni-cycle without getting chaff-marks and they let me work from 100% of the time because I'm old and they don't want me to die on company property. 😀
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Been here less than 10, hope to get 7 to 10 more before retirement. 🙂
I would still be curious as to how others manage their sprints. I still think it shouldn't be a one size fits all for the entire IT department. Not everyone has work that easily fits in two week increments.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. -
What I "love" about these scrum sprint agile and the newer cicd developments is that most managers think it will speed up their sloppy work.
They still don't have a clue about the data they are generating or consuming, heck they even think it is up to the load team or dba team to handle their bad data, until we use the power of our engines to avoid bad data from being loaded. Then it is our fault their load doesn't get processed on time, in time, every day.
It only supports short visioned, narrow sighted development .
Johan
Learn to play, play to learn !Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:- How to post Performance Problems
- How to post data/code to get the best help[/url]- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
- Johan Bijnens wrote:
What I "love" about these scrum sprint agile and the newer cicd developments is that most managers think it will speed up their sloppy work.
They still don't have a clue about the data they are generating or consuming, heck they even think it is up to the load team or dba team to handle their bad data, until we use the power of our engines to avoid bad data from being loaded. Then it is our fault their load doesn't get processed on time, in time, every day.
It only supports short visioned, narrow sighted development .
It supports what I've always said... "If you want it real bad, you'll usually get it that way". 😀
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
That's a great quote Jeff. Reminds me of a conversation I had yesterday. They wanted me to just write some SQL to pull from a table I don't know any thing about, in a different database(I've never worked with this db), on the same server. I'm not going to do it at this time. I've reached out to someone else who does have the knowledge of that area and I'll see if we have any other options. The huge hang up here was just trying to get someone to do the research in an area I don't know and I don't have access to.
It seemed like a 'band-aid' approach to just write the SQL and move on without doing more research. Or for those who remember the term 'spaghetti code'. There is a ton of that stuff I've seen here. For example, an SSRS reports reads from a table the isn't one of the 'core' tables. So I have to research where it is created, find it is created in a monthly SSIS package. Ok, good idea, helps performance of the SSRS report. But I look at the SSIS package, it call a stored procedure. Ok I find the stored procedure and it uses a view as one of the sources. And I kid you not, that view is calling another view. After looking at that view I can finally see the source table and the source issue.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. - below86 wrote:
For example, an SSRS reports reads from a table the isn't one of the 'core' tables. So I have to research where it is created, find it is created in a monthly SSIS package. Ok, good idea, helps performance of the SSRS report. But I look at the SSIS package, it call a stored procedure. Ok I find the stored procedure and it uses a view as one of the sources. And I kid you not, that view is calling another view. After looking at that view I can finally see the source table and the source issue.
Heh... I've taken to referring to such code as "The Maine Code" (with no insult intended to the folks living in Maine). Maine is the state where the term "Can't get der frum here" seems to have come from in the form of a joke decades ago.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
We currently do 2 Week Sprints both for Application Development and Database Development/Management -- we have Epics which get broken down into smaller pieces the largest single project being 16 hours and we easily get several these done in a single week. The biggest load ends up falling on Testing as we have several development teams and most likely not enough testers. However, we have established restricted time periods when deployments can be made, the restriction is twice a day once in the morning and once in the late afternoon. This gives the testers more time to focus on things without the environment suddenly changing. Further every so often (not sure of how often) they schedule a 1 week Sprint of no development so we either do Spikes or Documentation as this allows Testing the chance to wrap up certain longer aspects of testing without getting any new development being applied to the environment and thankfully it gives developers time to actually create the much needed documentation that is always critically needed but never gets done as it is always getting shoved to the back burners.
-
Thanks for the response Dennis on the main part of my post. I do see how this 2 week sprint works well for application development. But again on the DW side, back end processing, the two week sprint is annoying. A lot of our work really doesn't fit that cadence, and we have a bunch of 'reaction' work that pops up each day if not several times a week.
I just had someone set up a new 'project' for me. But they created 4 different tickets for it, an Analysis, development, code review, and a move to prod . This is the standard way they are doing it right now.
I know it won't be the case on this project. But what if I determine no work can be done, or there is a different solution. Then I've only used 1 of the 4 tickets and the other 3 have to be cancelled. Why not just create the tickets you need as you go. If you do the analysis and need to do development work, then you create that ticket, and so on.
They are trying to sell this to us as 'being able to get credit for the work you do'. As I said before we are using a point system to set for each ticket based on the estimate of work. And now some of us are getting questioned on the number of points we have. Not because they think we don't have enough, but that we have to much. They have defined 1 point as up to a half a day. two is anything less than 2 days, three is anything greater up to a week. If it's more than a week you have to break it up. Doesn't make sense to me because we have two weeks, so why couldn't I just have 2 week long tickets for the sprint.
Since my current sprint they think I have to much I have had to turn people away for some work they need. I tell them to create a ticket and we will see where it lands in priority.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. -
The Micro managing is going to get worse. Moving to having a scrum every workday. And now if you don't get the tasks you agreed to at the start of the sprint completed by the end of that sprint it will be counted against you at your review. It also sounds like we will have to have meetings to discuss each Jira ticket before we can even start on them.
This kind of reminds me of what went on at my prior job. They were trying to make things so difficult on people that the people would just quit. They did it this way because they were going to let a lot of the staff go and didn't want to have to pay severance packages to everyone.
Why can't there be a job/company out there that will let you just come in and do your work without all the BS. I'm not asking for God like authority or not to follow standards on how to do changes/updates ect..
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret. -
Lordy... such companies exist but, man, they're very rare. Most companies are like the one you speak of... they've adopted a horribly misshapen, grossly incorrect, interpretation of what "Agile" is and have turned Developers into assembly-line workers or oarsmen on a slave ship. They demand estimates but consider those estimates to be written in stone. I guess there are some people that thrive on that sort of thing... I'm definitely not one of them.
I have no sage advice here except to maybe try to find a different place to work where you don't have to row to the sound of a beating drum. Good Recruiters can help but finding good ones that have the candidate's best interest at heart is also very rare. Considering the intent you mentioned, you should probably do that anyway because if they want to get rid of you, they don't actually need a reason.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply