|
I am currently enjoying our 3 week iterations now being divided into three 1 week iterations by an administrative process to track what we are doing each week, its not like our ALM doesn't show what we are working on or there isn't source history to see what we check in day to day. So now we have 3 mini iterations inside of our actual iteration with planning and commitment and testing grouped around half features and disjointed efforts until we come to our 3rd mini iteration. Management fails to see how this is not putting into our ALM a 3 week iteration but functionally operating with 1 week iterations. But yay for tripping our overhead, making our stand up and always run over by talking about are we going to make this weeks progress every day and adding a new weekly meeting to plan and commit for our next weeks work. My all time favorite poo poo storm that had come out of this system is committing same week to a production push that relied on code changes the day prior, QA fails and we miss commitment and management is like HOW DID THIS HAPPEN? Tomorrow I get to live through another planning meeting on how I will be planning for more planning now, I remember when most of my time was writing code.
|
#
?
Jan 22, 2016 07:09
|
|
|
|
| # ? Apr 20, 2024 02:30 |
|
|
Make sure you have a planning meeting to plan to write code after you plan booting your workstation.
|
|
#
?
Jan 22, 2016 14:09
|
|
|
Volmarias posted:I'm getting into serverside programming after about 7 straight years of doing Android. As someone that loves serverside programming, dealing with Android was always a source of frustration. Welcome to the club. 
|
|
#
?
Jan 22, 2016 14:27
|
|
|
Now just get into embedded Linux kernel development.  Once you do you get a free dog collar and nipple clamps!
|
|
#
?
Jan 22, 2016 14:34
|
|
|
Having worked in a couple 'agile' teams, and just this week gotten my PSD I, I feel good saying that the unfortunate fact of Agile in general is that it's a paradoxical management structure more than a development practice. Because for Scrum/Kanban to succeed what you really need are: -Commitment to the process from the organization as a whole -A team of qualified, motivated individuals The problem is that almost every project will lack the first at some level, generally due to politics. And having the latter will likely mean success *regardless* of what methodology you're using to get there. But since Agile is the buzzword lately, everyone wants to be 'Agile' so they try really hard to cram mediocre developers into their homegrown "Agile but" framework, and things fall apart as a result. Agile is communism - seems pretty reasonable on paper - but introduce actual human fallibility and it's a clusterfuck.
|
|
#
?
Jan 22, 2016 15:42
|
|
|
ChickenWing posted:That's a bit of a paradigm shift So far, the fact that everything seems just kind of magical, in a bad, nondeterministic way, and there's just a ton of stuff to actually get something to the point of testing anywhere outside if your desktop. Obviously, that can come up with Android too thanks to oem mistakes, but it feels like it's such a high barrier to prototype something. Honestly, I did this briefly before, the better part of a decade ago, and very briefly several years ago to try to support something we were building. It never clicked with me the way Android did. I'm hoping it gets better this time. I have very bad memories of just trying to loving deploy stock Jenkins, no changes, just the loving .war, back at Amazon, and it won't quite be as bad here, but still. HardDisk posted:As someone that loves serverside programming, dealing with Android was always a source of frustration. Thanks.
|
|
#
?
Jan 22, 2016 16:08
|
|
what are you finding to be the hardest part of the transition?
|
Cuntpunch posted:Agile is communism - seems pretty reasonable on paper - but introduce actual human fallibility and it's a clusterfuck. I like the Agile experiment we're running at my company overall for one particular reason - once the planning is done and we actually start the sprint, management gets out of the loving way and lets us work. Most of the time, at least, and if they do start meddling we can politely tell them to butt out. There hasn't been any blowback on us for that so far. It's pretty nice being able to decide how much we can get done and how we get it done, entirely on our own.
|
|
#
?
Jan 22, 2016 22:17
|
|
|
Che Delilas posted:I like the Agile experiment we're running at my company overall for one particular reason - once the planning is done and we actually start the sprint, management gets out of the loving way and lets us work. Most of the time, at least, and if they do start meddling we can politely tell them to butt out. There hasn't been any blowback on us for that so far. It's pretty nice being able to decide how much we can get done and how we get it done, entirely on our own. But wait for a time leadership will pat themselves on the back and be tell each other, "We did a thing, YAY" And then they will realize there is less of a need for them to be around for development and will try to interject themselves into the process and gently caress it all up. I have seen certain personalities believe that a project will fail without them baby sitting developers for 3 weeks straight.
|
|
#
?
Jan 23, 2016 01:29
|
|
|
Largo Usagi posted:But wait for a time leadership will pat themselves on the back and be tell each other, "We did a thing, YAY" And then they will realize there is less of a need for them to be around for development and will try to interject themselves into the process and gently caress it all up. I have seen certain personalities believe that a project will fail without them baby sitting developers for 3 weeks straight. The management at my company doesn't appear to have that particular personality issue. That's not to say it's perfect; my boss for example tends to thrive under stress and exudes this aura of mild panic when something goes wrong. But he also generally responds well when we tell him to back off (politely) and let us deal with it, as long as we keep him in the loop.
|
|
#
?
Jan 23, 2016 06:06
|
|
|
Che Delilas posted:The management at my company doesn't appear to have that particular personality issue. That's not to say it's perfect; my boss for example tends to thrive under stress and exudes this aura of mild panic when something goes wrong. But he also generally responds well when we tell him to back off (politely) and let us deal with it, as long as we keep him in the loop. My team has changed hands a few times and under one leader we had our good practices go to poo poo, I am just a little jaded after seeing hard work going into a good process get ruined becomes some one higher up is insecure about not being in absolute control of every aspect.
|
|
#
?
Jan 24, 2016 07:22
|
|
|
My team at the new job has literally never done anything related to project management methodologies, ever. We've had 12+ hours worth of meetings already and we haven't even got the data model down on our new project. I'm being looked to as the major driving force for change re: "being more Agile" and bringing the whole approach to the team. I have like a year of dev experience at most. We have a QA department that we don't seem to interact with much, if at all. Everything in the project seems to be headed towards a waterfall approach, and most of the company's infrastructure is incompatible with OSX, which all the devs use and literally no one else. We can't build Docker containers locally because the company's VPN blocks downloading stuff from the Debian mirror servers. gently caress it, I'll kick rear end anyway. Bring it on 
Pollyanna fucked around with this message at 08:04 on Jan 24, 2016 |
|
#
?
Jan 24, 2016 08:00
|
|
|
No but seriously, I would really like some advice on getting middle management at a dinosaur of a company on board with agile. The team isn't much of a problem - it's only two or three of us - but I can't help but worry that our product owner/manager dude is totally ignoring the concept of "working with the customer", and a lot of assumptions are being made. We've already got wireframes, which is fine, but those need to be translated into a prototype or we won't be able to tell if we're going in the right direction or not.  All I know is that I gotta push for change, and the company seems to be willing, cause they're being threatened by newer companies who are in a prime position to take their share of the market, and they hate that, so they're looking for a way to get their edge back.
|
|
#
?
Jan 24, 2016 08:19
|
|
|
Pollyanna posted:No but seriously, I would really like some advice on getting middle management at a dinosaur of a company on board with agile. The team isn't much of a problem - it's only two or three of us - but I can't help but worry that our product owner/manager dude is totally ignoring the concept of "working with the customer", and a lot of assumptions are being made. We've already got wireframes, which is fine, but those need to be translated into a prototype or we won't be able to tell if we're going in the right direction or not. The non-joke answer is to gain enough experience to know how to manage upwards, build consensus among key team members, then just start doing poo poo the way it should be done and use your built-up social and technical capital to make the team follow. Then act like it's always been done this way and why are you rocking the boat now coworker peon Bob and/or manager PHB Stacy? The sheep will follow. You can build a poo poo-ton of capital by looking for highly desired features that haven't been delivered yet then doing them on your own without telling anyone (thus no opportunities to gently caress it up or say no). It requires doing a poo poo-ton of homework, being able to put on your designer and product hats, and making absolutely sure you are delivering something of high value to the business. You also need to reveal it in the appropriate context (eg where the sales team or CEO sees it before middle management can claim credit for it or squash it). Watch for people who want to hitch themselves to your success-wagon and use them to legitimize the process (eg the PM who feels frustrated and knows you can get things done; your next cowboy feature then becomes an official feature "requested by product"). This is expert-level managing upwards and I don't recommend it until you have a lot of experience. If done right you can essentially rebuild the entire team and its culture over time, without ever holding official power. You can use that to transition into management if you like. This works equally well at a 100k+ employee software company and a small startup. If you make something great, all sins are quickly forgiven.* * If you make garbage the blowback will be epic.
|
|
#
?
Jan 24, 2016 10:36
|
|
|
Ender.uNF posted:The non-joke answer is to gain enough experience to know how to manage upwards, build consensus among key team members, then just start doing poo poo the way it should be done and use your built-up social and technical capital to make the team follow. Then act like it's always been done this way and why are you rocking the boat now coworker peon Bob and/or manager PHB Stacy? The sheep will follow. Ender.uNF posted:You can build a poo poo-ton of capital by looking for highly desired features that haven't been delivered yet then doing them on your own without telling anyone (thus no opportunities to gently caress it up or say no). It requires doing a poo poo-ton of homework, being able to put on your designer and product hats, and making absolutely sure you are delivering something of high value to the business. You also need to reveal it in the appropriate context (eg where the sales team or CEO sees it before middle management can claim credit for it or squash it). Watch for people who want to hitch themselves to your success-wagon and use them to legitimize the process (eg the PM who feels frustrated and knows you can get things done; your next cowboy feature then becomes an official feature "requested by product"). There are so many ways this goes wrong, and the fantasy that you'll do some reveal to C-level and they'll all think you're a diamond in the rough and make you the new management is a joke.
|
|
#
?
Jan 24, 2016 11:52
|
|
|
Destroyenator posted:This may work for some people in some places but as a junior level new hire this won't be possible for you. Here's how it went down for the one junior-level hire that tried it, which also coincided with an executive at the top encouraging new ideas. The new hire of about a year got some leeway to try something new by talking with that executive. She was able to try out a pilot project on scrum to demonstrate measurable goals. At the same time, she explained agile practices to devs via silly team building exercises, retrospective format, etc... After the initial project was a success, she got a piece of the training budget for devs PMs, and managers to attend some "Agile day" thing. And then our team adopted Scrum a couple of months later and iteratively improved over the next 6 months into a functional team despite the odds. Unfortunately all the politics and a few middle managers caused enough stress to drive her out of the company.  But those same managers were rapidly losing what social capital they had left and soon  Two teams ran with a Scrum and Kanban work flow respectively, while other teams had various degrees of success. A year after that and the movement to "be Agile" is still popular and the other teams are coming around as well.  Basically what Cuntpunch wrote above.
|
|
#
?
Jan 24, 2016 16:09
|
|
|
Thanks, guys. That's been my experience with agile as well. As soon as you start trying to deviate from the prescribed methods in the books, things start to fall apart, and I'm pretty sure that almost no company sticks to agile 100%. I'm torn between implementing it as strictly as possible, and simply taking the short iteration loops/prioritization/anti-waterfall concepts from the methodology. I'm not gonna try going cowboy. That's a recipe for disaster. Not communicating with the customer/user on the product you're making means you'll go off the rails very quickly and won't make something particularly great. And I've got nowhere near enough clout to manage upwards, but I do have the ability to push for better practices. My work is certainly cut out for me. It's definitely not like I'm an agile expert brought on to revolutionize the workspace, nooo gently caress that. But I do legitimately want to improve our project methodology because it's very easy for a project here to go totally off the rails. Also the company has a history of bringing on vendors, contractors and proprietary software for a few months then subsequently dumping them and pushing the results off onto developers  The good thing is that iterative prototyping is totally possible since people at the workplace go loving gaga for meetings, so I'm free to show our current software to the customer every sprint end! I think.
|
|
#
?
Jan 24, 2016 16:34
|
|
|
spacebard posted:At the same time, she explained agile practices to devs via silly team building exercises, retrospective format, etc... After the initial project was a success, she got a piece of the training budget for devs PMs, and managers to attend some "Agile day" thing. For me, that was the absolute worst part about switching to Agile. So many coddling meetings about why multitasking is bad. So much not listening to our project team, in particular, about our doubts that Scrum was the best fit. Fortunately, they finally gave up and switched us to Kanban, after the fortieth sprint planning that went off the rails with us complaining. A few months later, they suggested that Kanban wasn't working because our projects were taking too long. We all went, "Nope."
|
|
#
?
Jan 24, 2016 19:48
|
|
|
I inherited a department doing a textbook rename all the waterfall things agile things and keep doing them with extra meetings on top. Now we do a mixed Scrum/Kanban with the focus on delivery. Not everything is perfect or even great, each sub-team really makes or breaks this on their own but overall much more high quality code sees the light day and does so much faster than it used to.
|
|
#
?
Jan 24, 2016 21:52
|
|
|
I like Kanban a lot, actually. I'm wishing I could work it in to our project approaches, but it'll need a PM who understands how to properly prioritize tasks instead of just adding new features on the top of the stack every day. We're about 3-4 weeks into our new project, which came out of a proposed feature for an existing one, and we've had like three sprint meetings where we ended up giving out absolutely no work. Since the PM wants this project to be priority over another pre-existing one, we're not touching that, but we don't have tickets for the current one outside of "we need to figure out our data model and make a confluence homepage". So I just spend my time reading books from PragProg, which is still productive.
|
|
#
?
Jan 24, 2016 22:41
|
|
|
I think Kanban is ultimately 'better' if you've got an experienced team, but a good team should certainly be able to make Scrum work as well.
|
|
#
?
Jan 25, 2016 09:13
|
|
|
Here's a general question that's somewhat an inversion of my previous statement: How *do* you make Agile work when there are drastic skill discrepancies amongst the development team? It seems like that's the other thing somewhat inherent to development is that you will have strong talent on one end of the team's spectrum, and dead weight on the other - whether it's for "coast until retirement" career folks or just "if it isn't something I learned in school then it will take me 9 hours to do basic things" or any of the other usual bad-dev tropes. My experiences repeatedly is that you either end up in a situation where the better devs turn into tacit janitors - let the bad devs write horrendous code, come in as mentors/reviewers/whatever and clean it up. Or you end up with the better devs just getting the work done super quick and the bad devs sit on their hands 40 hours a week feeling left out. I mean obviously "only hire talented people" is a great answer, but that's not realistic at all, so what's the real-world solution?
|
|
#
?
Jan 25, 2016 14:41
|
|
|
Well, the first thing that springs to mind is code reviews so that people's code quality is up to snuff, but that doesn't solve the code janitor problem. I think a better way is to employ pair programming so that the bad code never exists in the first place, but then the dev time is split between multiple tasks, which seems antithetical to common adages regarding focus. There are a few things that I'm critical of in agile, and that's one of them. It seems to assume a low delta of skill among the team members, which is rarely the case. I'm not sure how to address the problem, but pair programming is at least beneficial and collaborative. v  v
|
|
#
?
Jan 25, 2016 14:53
|
|
|
Cuntpunch posted:Here's a general question that's somewhat an inversion of my previous statement: Do code reviews. This gives traceable, explicit evidence that they are loving up and ruining the team's velocity. This can go down three roads: They will realize they are loving up and get better. (If management gets it) They will be fired and competent people will take their place. (If management doesn't get it) Management will make you stop doing Agile because "there was never a problem with Dinosaur Joe's work before!"
|
|
#
?
Jan 25, 2016 14:59
|
|
|
Cuntpunch posted:I mean obviously "only hire talented people" is a great answer, but that's not realistic at all, so what's the real-world solution? I don't think there's any practical solution to turn bad devs into good devs other than replacing. If they aren't willing to improve themselves they just won't, and there's really nothing else to be done.
|
|
#
?
Jan 25, 2016 15:12
|
|
|
Project planning methodologies are only a tool, they can't fix management foul ups. The best thing you can do is adjust the available time planning for developers that you know will underperform, such as dividing their hours by 4 for the board so that they only get assigned 10 "hours" of work per 40 hours of availability. This way, when they're later with Project Dingle, it doesn't blow your estimates. Similarly, block out 20 hours per week for "dragging the team upwards" for whoever your good developer is, etc. Make sure that code reviews, tests, etc are accounted for in the effort for each story and task.
|
|
#
?
Jan 25, 2016 15:15
|
|
|
Yeah, TFS has a 'capacity per day' field that works very well for that purpose. In the end though, hiring talented people is really what it's about. Remember "individuals and interactions over processes and tools" 
|
|
#
?
Jan 25, 2016 16:39
|
|
|
Messyass posted:Yeah, TFS has a 'capacity per day' field that works very well for that purpose. I haven't yet seen anyone really read that as anything other than "a million meetings, both scheduled and ad hoc, are great because INTERACTING!"
|
|
#
?
Jan 25, 2016 17:45
|
|
|
Cuntpunch posted:I haven't yet seen anyone really read that as anything other than "a million meetings, both scheduled and ad hoc, are great because INTERACTING!"
|
|
#
?
Jan 25, 2016 17:49
|
|
|
Cuntpunch posted:I haven't yet seen anyone really read that as anything other than "a million meetings, both scheduled and ad hoc, are great because INTERACTING!" In the groups I've been in, we've always read that as "given an option between just turning around and talking to each other vs. establishing a formal process for something, pick just talking to each other". For example, if someone needed to do something that meant no one else should push for thirty minutes, instead of building up some process of notifying people through a tool and things like that, just loving turn around and say "Hey, no one push for thirty minutes, okay?" and everyone says "Cool" and turns back around and gets back to work. If you read that as "more meetings" or "more tools", then you're doing agile wrong.
|
|
#
?
Jan 25, 2016 18:05
|
|
|
Axiem posted:In the groups I've been in, we've always read that as "given an option between just turning around and talking to each other vs. establishing a formal process for something, pick just talking to each other". For example, if someone needed to do something that meant no one else should push for thirty minutes, instead of building up some process of notifying people through a tool and things like that, just loving turn around and say "Hey, no one push for thirty minutes, okay?" and everyone says "Cool" and turns back around and gets back to work. That only gets you so far when your team is colocated across the world and you have devs on the East Coast, West Coast, Europe, and India.
|
|
#
?
Jan 25, 2016 18:16
|
|
|
Cuntpunch posted:Here's a general question that's somewhat an inversion of my previous statement: Other than pair programming, as a dev lead I made sure to provide technical details in stories (before the story was groomed or estimated). Not a strict blueprint but a general idea as to how a story should be approached. This helped normalize estimation and made other secs more confident to pick up stories on their own. And then I had "office hours" where I was available. This usually reduced my focus to 50-60% though. On the team I'm on now we are expected to estimate just on the story and hardly review acceptance criteria, in hours, then create sub-tasks on Jira afterward. Seems sort of backwards to me.
|
|
#
?
Jan 25, 2016 18:18
|
|
|
Basically, just don't be a bureaucracy.
|
|
#
?
Jan 25, 2016 18:33
|
|
|
Destroyenator posted:This may work for some people in some places but as a junior level new hire this won't be possible for you. Your best hope is that someone more senior (either technical or management) feels the same way and you can be a positive vote for them. If someone asks you what you think then "you've read about some ideas for process but haven't worked with then yourself, but you would love to hear what they think about this article/link/whatever". This is all down to your lack of professional experience, when you've got three or four years and a few projects under your belt you'll be able to make more impact. Everything in its measure; you can't be cowboy all the time. That's why I said it's an expert level technique. I never said they'd make you the new management after a reveal. You have to build credibility which takes a long time. You may also be working for morons in which case you just survive it, possibly for the experience, then move on. And I definitely don't want to be known as a developer who just follows simple instructions. I want to be known as a 10X developer who is passionate about what I work on and makes the product and the team better.
|
|
#
?
Jan 25, 2016 18:49
|
|
|
spacebard posted:Other than pair programming, as a dev lead I made sure to provide technical details in stories (before the story was groomed or estimated). Not a strict blueprint but a general idea as to how a story should be approached. This helped normalize estimation and made other secs more confident to pick up stories on their own. And then I had "office hours" where I was available. The latter is a huge part of my current struggles, almost exactly. We get some reasonably broad "hey here's a feature/bug/etc" and then it's a total crapshoot after that. If it's a bug that's previously been investigated, we tend to have decent analysis notes(depending on who investigated) - but if its a feature it tends to be big-picture and only a couple of us even ask questions looking for specifics. Acceptance criteria? Made up on the fly by the QA team that'll be testing the feature~
|
|
#
?
Jan 25, 2016 19:05
|
|
|
Ithaqua posted:That only gets you so far when your team is colocated across the world and you have devs on the East Coast, West Coast, Europe, and India. Replace "turn around and say something" with "say something in slack". The details change, but the general idea of prioritizing making communication easy over creating process to solve problems resulting from poor communication still applies.
|
|
#
?
Jan 25, 2016 21:06
|
|
|
ughughughughughguhguhguhguhguh I opened a defect a couple weeks ago regarding a documentation gap. In the time between now and then, the documentation was updated so that the gap no longer mattered. Business team -just- got a look at the defect and now are probably going to look at me like I've got two heads. This is made much better by the discussion we had a while back after I shotgunned like ten other documentation defects at them that they didn't believe the defects were valid (they were).
|
|
#
?
Jan 26, 2016 14:42
|
|
|
I'm a little worried about my current workplace's project methodology. We had a...spring planning-like-thing today for deciding what to do about our new project that spun out of an existing one. Here's a few things I heard and learned in the ~2hrs of meeting time:
 I was told by another engineer a few days back that part of the reason I was brought on was to help drive the team closer to agile and to improve our process. I genuinely don't know if I can do this all myself. I'm still learning the basics of agile and even though I'm reading as fast as I can about creating user stories and making tight iteration loops, I still am not the Expert Team Fixer they clearly need. I'm torn between scrambling to save this project, or just sitting back and letting it go off the rails, distancing myself from worry. I feel too bad doing the latter, but I don't know if I can take on the responsibility of the former.
|
|
#
?
Jan 26, 2016 19:04
|
|
|
ChickenWing posted:Oh my god. I felt super smart when I figured out you can do tests for configurations. For example we have a bunch of "permissions" defined with Enums. And you also need to define in an xml for which permissions are granted for different user states. So when you add a new permission you need to change stuff in two places. So I made a test that checks that all the Enums are defined somewhere in the xml. So if someone forgets to add it to the xml the test goes "This permission exists but is never used anywhere". Works really well when one thing has to be added to multiple places. These are my new favorite kind of tests. If you can't make something unforgettable, make a test that fails when you forget the thing. Your teammates will also thank you when your configuration test saves them time on debugging!
|
|
#
?
Jan 26, 2016 19:35
|
|
|
Pollyanna posted:I'm a little worried about my current workplace's project methodology. One thing that can really gently caress up a project is having too many people on it when it starts. It sounds like you have too many people on the project.
|
|
#
?
Jan 27, 2016 06:32
|
|
|
|
| # ? Apr 20, 2024 02:30 |
|
|
There seems to be some conflation of Agile and Scrum. Scrum is one of many Agile methodologies, including, but not limited to: RAD, Scrum, Kanban, UP/RUP, and XP/Paired -- I'm just listing ones I've worked with directly, there are a lot more, including all of the *DD methodologies. From my experience, Agile is primarily about getting people who are not good at synchronous, real-time communication to get good at synchronous, real-time communication. Secondarily, it's about the collection of data to be able to determine a development team's velocity, which informs product roadmap and/or allocation of development time among projects within a project portfolio competing for development time and budget. Scrum is training wheels for Kanban. The training wheels come off when you have a self-motivated team that communicates effectively in real-time, whether co-located or remotely, and when that team is able to measure their velocity and report it in as close to real-time as possible. Generally speaking, this takes longer than a couple of sprints, especially if you want the velocity number to be defensible to others: stakeholders, management, etc. Barry Hawkins (Riot/Blizzard/Netflix - https://www.linkedin.com/in/barryhawkins) does a great video about Agile anti-patterns that I watch as part of my quarterly personal retrospective: https://vimeo.com/43603455
|
|
#
?
Jan 27, 2016 09:41
|
|
