Well, now instead of working towards progress on a calendar as measured by functionality we've added, and working mostly in 1, 2, 3 or even 4 week chunks, we now have to break everything down in terms of 3 days tasks. And every two weeks at the end of a sprint we can look back at tasks we've each closed and measure our velocity.
How do you do agile when the requirements are vague, the solution space filled with unseeable potholes and an emphasis on velocity?
Nonsense snark above aside, this is a genuine question.
(Best as I can tell, agile is seen by some as a way to force pesky software developers to forego design and move straight to coding.)
How do you honestly developer software under agile, when you just don't have a fucking clue as to what the solution space looks like, what unknown problems are going to come up, and the manager is concerned with velocity?
The worlds of DevOps and CICD were an exciting mystery to me, as a Business Analyst and Product Owner working with Development/Operations teams but never in them.
Everything i found online was either or me too low level or too high (#goldilocks). I spent some time learning the nitty gritties and condensed it right down to something I feel is juuust at right - aiming to help out others looking for the right entry point into the fields. Checkout my 6 part article series on Software Delivery, DevOps and CICD for the uninitiated! Please read, share with colleagues/friends and let me know your feedback :-)
For context, I am a Software Engineer who has taken over the scrum duties for my team.
My organization is starting to phase out the scrum master role, and my team's old scrum master has moved into an agile coach role. I haven't been able to talk to our agile coach, as she has been dealing with some personal issues over the last month, so I was hoping to get some other perspectives on "team values".
Strictly from my "engineering" mindset, I don't see the benefit of creating a concrete set of team values, as I don't think anyone on my team would look at them. However, for our upcoming project, we will be interacting with a few other engineering teams, so having a set of clearly laid out values might be good to put together a sense of camaraderie and accountability.
For that reason, I am leaning more towards holding a meeting where the team can come up with team values, but I am a little lost as to how to best facilitate it. I know they will have the same questions that I do, so having some additional information about the value added would be nice.
I am new to a company, posted the other day about it, but basically I've got 2 or 3 teams of 7 total, that are not development, they do back end work or design / architecture. Their teams are extremely specialized in that basically, every team member is an individual contributor and none of them have inter-dependencies...
How is someone who's job is to say design the deployment of 10 new buildings plumbing, without the need for anyone else, suppose to follow scrum other than to just basically create a velocity chart to show their individual progress? Not to mention, how are they suppose to make an MVP of a design document?
Wondering if anyone has any interesting techniques, tools that allow for a really productive and useful session at the end of a project across all teams involved to look back and do a 'lessons-learned'
The project was a migration project with multiple epic releases within. I was thinking of creating some sort of timeline, putting static release cards on then giving everyone red, yellow or amber sticky notes detailing what they thought at the time.
If anyones got any good ideas or ways we can better capture metrics it'd be much appreciated. There will be around 70 attendees.
I've worked in an agile environment for the last 4 years, most of which was executed very poorly, it was usually waterfall jammed into sprints but it was experience. I got a chance to play scrum master along with my other role on the team for about 8 months on a project, I liked it so much I went and got certified, which was a joke really... 1000$ and I spent 2 days in a hotel conference room getting the bare minimum understanding of scrum, then an open book test I could of aced in my sleep, now I'm apparently a pro... That being said, I've done a decent amount of research on my own, along with having several very experienced agile coaches along the way that gave me advice etc.
Now, fast forward to today, I got offered a position as a scrum master and I accepted.
I am in charge of 6 possibly 7 teams... 3 possibly 4 of which haven't ever done an agile approach of any kind. All of the teams are going to be on the same cadence, we're sticking to scrum as text book as possible.
I'm running into issues with how in the hell am I going to manage all of these teams inner dependencies? Some teams need other teams to do work for them to be able to meet their MVP. This company works 24/7 and no one has a second of time to actually go to a meeting much less participate in backlog grooming. But, most of these teams don't have real product owners, they're just sticking developers or managers into these spots and those people don't have time to actively play that role dedicated. So, I'm extremely worried without a company wide clear understanding of what is priority, team 1 might need team 4 for something but team 4's priority doesn't even put that dependency into a sprint, and no one knows that because no real PO is there to help them understand that... Not to mention, there's no cross talk between teams outside of me...
One of the directors wants to split his team into 2 teams, because his developers do completely different things and are not at all related, in fact, almost everyone on his team is a solo operator... He doesn't believe in cross training and thinks it works better if everyone functions in silo's...
How do I demonstrate the value of cross training and the value of backlog grooming and cross team grooming? How do I avoid looking like what I'm implementing isn't actually doing any good, if I can't get them to actually do it the way it needs to be done?