Treating agile like a process, defeats agile.
-
AKA Internal interviews are weird
Do you have any questions?
What kind of programming environment do you use?
Uh.... Visual Studio (pause that could have 'duh?' inserted), I don't understand what you are asking. Are you asking what other technologies do we use?
What kind of source control do you use?
Mercurial (pause, scratches head).
(Skipping the rest of my normal list of questions)
He continues. We are also used scaled agile framework.
Ah yes, I have experience in that.
Good, then maybe you can teach us a few things. It's a work in progress.
It's hard to come up with questions, when you had an internal informational group 2 hour meeting on the position 2 weeks ago, with powerpoint presentation.
It's not like I can say, hey, all those things on this list of requirements, I have that experience, do I get the job?
So, um, how can I expand my list of questions, so I don't look like a dork? Any suggestions?
-
We are also used scaled agile framework.
What? This is basically: we use JIRA
What kind of programming environment do you use?
I'm not sure, but it seems the interview was for a Windows development thing, right? IDK, but MS stuff is kind of a closed standard stack: VS, ASP.NET, C#, IIS & MSSQL so maybe that's why the guy was confused?
Now, those questions seem sane enough, but not to an HR drone. Always get to know who is doing the interview. If HR drone, I ask questions like family flexibility, WFH, dressing politics, that sort of stuff.
When talking to a technical one ask that kind of stuff: source control, machine setup, using my own OS ( I won't work anywhere I'm forced to use Windows only, sorry ), CI, etc. A washed down version of the Joel questions is ok and right to the point.
So, um, how can I expand my list of questions, so I don't look like a dork?
You're a software developer, you're a dork, get over it... even brogrammers are dorks that go to the gym.
-
Are you conducting the interview, being interviewed, do you need an advice on what questions to ask the interviewer, how does the 2 hour meeting calculate into this, WHAT THE HELL ARE YOU TALKING ABOUT.
I mean, I know it's 10AM here, but your posts seem to increasingly read like James Joyce's rejected writings to me.
-
good questions are things that are (or look like they are) specific to that company. You get points for asking any question, but the big points are in using the questions to make it look like you give a shit about joining the company or not.
Asking things like "I saw you released a new patch for product X a few weeks ago, what was the process of deciding what changes would go in and testing it like?" or "I noticed you have a wide portfolio of products, do developers move around between products, or are teams dedicated?", or "what steps did you take to ensure successful contract X did not go over budget?" or something like that.
It adds work to your prep, but there's no replacement for having "I obviously did some research on you specifically" questions.
edit: I just reread and it says internal interviews, huh thats a lot harder.
I guess asking my old favourite "do you have any reservations about me filling this role?" might be a good one, it gives you some insight into how they feel it went, demonstrates ability to ask tough questions and ask for/accept criticism, and an opportunity to address anything they happen to mention, (usually the social contract is too strong for them to say anything other than no, so if they do it's non-trivial and you should attempt to address it)
-
I think @xaade is the interviewee.
-
@Eldelshell said:
What? This is basically: we use JIRA
No, SAFe (Scaled Agile Framework) is an approach for large organizations (typically over 500 developers) that provides everything from high level portfolio management (where million dollar budget decisions are made) down to the small team sprints.
Didn't realize xaade worked in that type of environment.
-
When I interview, and granted it's never been for internal stuff, I always ask specifics about the environment. If it's a .NET shop, what do they use for data access. Are they using WebForms or MVC or WebAPI, and if it's something that can be abused like WebForms are they using a presentation layer to separate the logic or is everything stuffed into code-behind files?
I use that sort of thing to gauge if they keep up to date with the best practices of their peers as well as make sure they aren't clueless morons. I've worked at one too many places that were all gushing about how they use the "latest technology" but the code was written like it was 2001 and nobody there had any clue about anything since.
-
Ditto the confusion, also why is it in Funny Stuff?
-
-
From what I can tell about their implementation, instead of having a product manager, the company infrastructure acts as product manager, and business requirements aren't collected from users directly through the manager, but through polls and communications with the various customers over time.
So basically the product manager is a chunk of the organization, instead of a person.
And this communication is handed down to the agile teams through a quarterly meeting.
I forsee one problem with this, and it could be handled informally, which is agile is there to provide functionality as it changes and to have constant communication channels with the user.
Quarterly meetings are anything but sufficient for the agile creed.
So, instead of being agile, at least this implementation as far as I know it, is just taking structural concepts used to achieve the agile creed, and divorce them from actually fulfilling the agile creed.
Correct me if I'm wrong, but that's how I see it.
-
how does the 2 hour meeting calculate into this
I edited to clarify.
The 2 hour meeting was a powerpoint presentation, presented department wide, to talk about the needs of this specific team and what the job detailed and what the structure of the team was.
Which made it very hard for me to ask questions, because they were already answered.
So basically my mind defaulted to my default list, and it looked like, durh you know that.
-
From what I can tell about their implementation
The sounds like a high probability of fubar. Typically the "up/down the chain" is about every 3 development sprints (sometimes 4).
Also there are working sessions that involve ALL the people being present (they are often held off-site to allow for hundreds or even a thousand or more to be in attendance. These typically last 2 days, and may occur on a quarterly basis. These are the strategic planning (are we coung to launch a new product, make a major shift in product focus). This allows all of the people in the various release trains to coordinate corporate resources.
-
Also there are working sessions that involve ALL the people being present (they are often held off-site to allow for hundreds or even a thousand or more to be in attendance
This may be the actual case, and I'm unaware. I wasn't given much details.
But even so, this does not fulfill agile creed IMO. It is an avenue for user interaction, but not at the pace to actually benefit from the agile teams.
In fact, I see SAFe as just a scheduling tool more than actual agile.
How can the product manager actually do their part if they only get input every quarter? At that point, they aren't actually needed as there is nothing to push back against.
But then again, SAFe scaled work generally moves slow anyway. Drastic needs are more pushed by regulation requirements, which change from year to year, than business needs.
You're selling versioned software at this point, and not really building software that is updated in place.
mixed feelings
-
xaade - We are getting a bit serious for this venue, but would love to carry on the conversation [it is trivial to locate me using this Identity].
Think of things are recursive, agile cycles wrapped within agile cycles, wrapped within.. Every three months is quite frequent compared to previous approaches were often multiple years for the $10M->$100M+ decisions.
If one follows the hierarchy of Goal->Initiative->Epic->Feature->UserStory, then this period is creating/maintain the backlog of Goals and Initiatives, Epics and Features are multi-sprint, and User Stories are delivered within a sprint.... Make sense?
The product manager should be getting input EVERY DAY (ok, perhaps not on weekends), but input at different levels of granularity.
-
I'm not so much serious, or stuck in my frame of mind, as much as speculative and curious.
However, this is the creed, and ultimately anything developed from it is just a framework for accomplishing the creed.
My problem is with the last point. "Responding to change".
IMO, SAFe is only accomplishing agile, iff change is as slow as every quarter.
I think in my environment, it is reasonable to expect that, because we deliver versioned software that is delivered yearly.
If we wanted more granularity, we'd have to change our approach, and drop the idea that you release versions that require all new equipment and software top to bottom.
Ultimately you do what works for you, and that's why I said that SAFe seems to be better suited to just helping keep a schedule rather than actually accomplishing the goals of agile.
This is not a criticism of SAFe, but just a frame of mind when comparing SAFe to the goals of agile.
In that context, SAFe can be simply another way to approach software design suited to its context.
So you have waterfall, agile, and SAFe which is somewhere inbetween.
-
iff change is as slow as every quarter.
Except that is not it at all. I don't know if I am communicating poorly or what....
When projects get big (And I mean really big, like 500,000 man-hours per year) in an organization that is running many independent product lines (think Microsoft with "Server", "Sql", "Office", "Developer", etc. as the product lines) the "BIG CHANGES" can not occur at any high rate of frequency.
That is the TOP level of SAFe, but it is not the only level. There are typically at least three tiers, with the bottom tier being the "classic agile" team [2-3 week sprints, 5-10 person teams, daily standups, sprint planning, sprint review]. The goal of SAFe it to coordinate all of these tiers together.
-
the "BIG CHANGES" can not occur at any high rate of frequency
Which are supposed to be broken up into the small changes and delivered as soon as a deliverable is ready.
Business people and developers must work
together daily throughout the project.I get that you need the coordinate large networks trying to parallel the work to make BIG changes.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.I get that massive changes occur at a lower frequency, but if these levels block the ability to respond to changes at the lower level, this is not agile.
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.Say you're working on a rewrite of Word. There should be nothing saying your team can't deliver it's branch for user testing to make sure the one feature you worked on fits the requirements.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.If your structure is such that you can't make these type of deliveries, it's not agile, it's simply a structure and coordination system that lets you schedule work in a large organization.
It is only incorporating structure from a specific implementation of agile, and removing the core concepts of agile from it.
-
There should be no blocking, incremental deliverables should be made every sprint so what you are talking about is not in accordance with SAFe at all.... Sound like your company is pushing something under the name of SAFe that is at best a bastardization.
-
Sound like your company is pushing something under the name of SAFe that is at best a bastardization.
It's speculation. I have no idea what they are pushing.
And like I said, right now we have a long delivery cycle and deliver in whole versions. If you want the new version, you build a whole new system. Our sales model is built around it.
I'm speculating that there would be no business push to deliver incrementally. And therefore, there would be no push to actually implement real agile, but mainly use it as a scheduling structure so they can meet requirements better and be more formal in their delivery.
So, it would be hard to deliver in an agile approach anyway.
I'm not aware of what SAFe really looks like.
I just know that a lot of people miss the boat when they start implementing agile, mostly because they focus on the processes which breaks manifesto line 1.
Individuals and interactions over processes and tools
-
Now that I can agree with completely. In fact there has been a very active discussion on LinkedIn about "a lot of people miss the boat when they start implementing agile, mostly because they focus on the processes which breaks manifesto line 1"..
So you have my sympathy, I just ask that you do not allow the poor experiences at your firm to skew what SAFe is (and is not).... Cheers!
-
Now that I can agree with completely. In fact there has been a very active discussion on LinkedIn about "a lot of people miss the boat when they start implementing agile, mostly because they focus on the processes which breaks manifesto line 1"..
They're agile. For lumbering apatosaurs.
