June 2, 2023 at 7:50 pm
Okay let me outline our process flow -- and being the Lead DB Developer I get to do more
Sprint 2 weeks -- 1st Week development -- Monday of 2nd Week Code Freeze -- 2nd Week do things that do not effect code - except for any bug fixes found in testing for one of the current sprints still in the process pipeline
During Sprints we have:
Daily 30 minute to 1 hour Teams Leads Meeting -- all the Scrum Masters (Team Leads) and Database Lead (me) and a few other higher eschelon folks.
Daily 30 minute to 1 hour Scrum Team Meeting -- all the individuals that are part of your specific team
Then you have the rest of the day. -- Next I have two Stories (tickets of 16 hours) one of which is dedicated to Peer Reviews and Helping other Developers and the other is for Deployments (as our Database Deployments are manual still) I have Deployments to QA Environment, PreProd Environment, and Prod Environment. Usually Sprint 3 deploys to QA, Sprint 2 deploys to PreProd, and Sprint 1 deploys to Prod and this cycle is continuous. (4, 3, 2; etc...)
Outside of those two 16 hour stories, I usually have several other stories but again no single story is more than 16 hours in length and I have been doing this for almost year now and the company itself for much longer than that. It works quite smoothly.
For instance let us say I am going to work on opitimizing one of our old stored procedures (as many of them desperately need it), so in Sprint 1 I first Reformat the procedure to meet our current formatting standards (which I had to get implemented after joining so yeah most of the procedures look like crap) as this usually changes every line without changing the code. This includes creating a Unit Test Script to show that the procedure produces the same results as it did prior to the reformatting. This goes into the process pipeline QA to PreProd to Prod. Then in Sprint 2 I have a follow up Spike to Analyze the procedure to determine if optimization will benefit the procedure. Then in Sprint 3 IIF the procedure was determined to need optimization I have a follow up Story to Optimize the procedure. Then perhaps in Sprint 3 and/or in subsequent sprints I may have a follow up story to do Part 2, 3, etc... if the Optimization requires a lot more time to complete. However, once the Optimization has been completed it goes into the process pipeline.
Note we do create some tickets ahead of time, but those are placed into the Backlog and then pulled into a Sprint if someone needs more work or as part of the Sprint planning session but we also create subsequent tickets whenever additional work is needed for a current story as well as on the fly tickets for things that pop-up out of the blue such as in response to a bug.
Further we have EPICs which are very large tasks that will consist of numerous Stories (some long some short but none longer than 16 hours). Basically, just about any project can be broken down into 16 hour increments -- completing one of these stories does not always mean something goes into the process pipeline it just means a certain amount of measurable work had been completed.
Now while we try to complete a Story that is in a Sprint during that Sprint, that does not always happen. Sometimes there are blockers or the individual got pulled away to troubleshoot alot of issues and could not complete the story. In this case, we move the Story to the next Sprint even if they had done most of the work already they will just get credit for it during the next Sprint. Now if someone got pulled into doing something adhoc (not part of the scheduled Sprint) that consisted of at least 30 min or more then a Ticket gets created for what they did and put into the current Sprint. This allows us to show the powers that be that yes the folks are busy. Further it lets them understand when more resources are needed. Since without that information they cannot plan for that.
For instance, our Testing Team is currently understaffed and we have had to make some adjustments for that until more quality folks can be found. Still many of their tickets do not get created until a development ticket moves to QA during the first week of the current Sprint. Whereupon they have testing tickets created for QA, PreProd, and Prod but the future tickets are placed into the Backlog for later retrieval.
Basically, if you have someone who understands how to run a proper Scrum, then the whole process is rather smooth. Granted from what I understand it was not always so smooth but with quality Scrum Masters and a quality plan we have been ironing out some of the kinks and making adjustments. For instance, because the QA staff is understaffed, periodically we have a non-development Sprint where the developers work on Spikes -- analyzation or documentation both of which are very important and the latter rarely done as much as is needed. As quality documentation can help bring a new employee up to speed a lot faster than the usual adhoc method, especially if the team is very busy.
I hope this helps you see how it can work, and why it is important to do. If you have any questions about any of this please do ask, I would be more than happy to help you understand the process (or help you perhaps with ideas to make yours better).
June 5, 2023 at 2:02 pm
I guess if it came across that I was questioning the process then I'm sorry. I do see how this process can work and is very much suited for those in an 'application' development area. I see that a lot of their work can be compartmentalized into nice little chunks. But I guess I also see all of the overhead it is creating to have to create 4, 5 or more tickets to accomplish a single task. To your example of fixing a stored procedure. To me that should be just one task, not broken down into multiple tasks over multiple sprints.
We have teams in our company that work on the Policy system and another that work on the claims system. This is the process they have followed for years, and I see it works for them. But I also see that when we need them to fix an edit or allow for a new value in certain fields it is at least a six month wait. And I partially blame this backlog on this type of process. Now back in the day of the mainframe, we developers had access to the code and could either make those changes needed or had someone work on them right away.
I just don't see this as a one size fits all approach. I'm in the data warehouse side of things(around 25 years of experience in DW) and our projects are usually larger more time consuming than those of the application side. Yes I can, and we are doing it, breaking these down into smaller tasks.
As one person put it 'it's like one process that those making steaks and potatoes' in a restaurant has will fit the other areas of the kitchen. That doesn't really work for the soup people, or those that make the deserts.
Maybe I'm just old and stuck in my ways, but my #1 strength is adaptability, hmm. I just see this now as Jeff pointed out earlier, it's micro management.
I mean I'm going to do what they ask for now, because I need the paycheck, but that doesn't mean I cant complain or push for change.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 5, 2023 at 11:16 pm
Actually that is not unusual and it has nothing to do with backlog per se -- let us say I have plenty of time during the upcoming Sprint 2 (but not Sprint 1 which has already started) and you came to me on Wednesday of Sprint 1. That Story has to wait until Sprint 2 (nearly 2 weeks) or worse you come to me after we have done the Sprint 1 planning then it has to wait even longer (a bit more than 2 weeks). So we will say it gets into Sprint 2, then it gets completed and moved to QA and thus into the process pipeline (2 weeks). Then during Sprint 3 it will move from QA to PreProd (2 weeks) and finally from PreProd to Prod (2 weeks). This assumes there are no delays or no serious bugs. That means a minimum of 6 to 8 weeks to move throw the full process pipeline and that assumes the next Sprint 2 is not already full of higher priority projects. So yeah minimum of 2 months with nearly 3 months not being unusual and that is just the normal flow of something through the full process pipeline.
As for DW that I cannot speak to at this time as I do not think I do that as of yet. Although I am in charge of the data within Databases and soon as I get my Admin skills up to snuff, I will be in charge of that as well. So what makes a DW change so much more time consuming than a complicated Stored Procedure and by DW do you mean Data Mining?
As for change yes not all change is good but it is always inevitable, however presenting alternate solutions when pushing for change is much more effective than just pushing back. It took me a while, and I had to present a full report on it, but I did manage to get Redgate brought online. Now we just need to get the time to, dig more into it and really begin to use it. Sadly, however, they did not get the full product as I had strongly recommended and I am not sure if that was intentional or due to a misunderstanding. Still, once we have this version up and fully functional then I will push for the remaining pieces.
So yeah don't complain it does nothing. Instead I would encourage pushing for change and backing that up with potential quality solution(s) and you will find that change is much more likely to occur. Just be sure to carefully walk that fine line between pushing just enough and pushing too much that you become annoying as that will stifle the change faster than anything.
That said, good luck in getting something better in place.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply