Try to, anyways. Depends on the pressure from mgmt and the bu and other activities I've got going on. As I always say, there is a price to pay for everything. I've been on projects where I've cut out meetings, interactions with the business unit, and adequate testing just to meet a deadline. The price is the rework and future maintenance of the product.
I have been in software and systems development since the late 1970s. Both from an anecdotal perspective from my own experiences, and from my studies to get an MBA, the best approach, especially with agile, is to have a team leader that is a senior software engineer, with experience and knowledge in business so he or she can communicate as well with customers (internal or external) as with developers.
All members of the team should report directly to the Team Lead - BAs, QAs, app developers, and DB developers. There is only one driver's seat on the team bus. Working as a team is essential, but when leadership is needed, only one leader is optimum. And the team lead must take the arrows for the team so they can be productive and not get bogged down by external issues.
At some places, the Business Analysts have risen up and hijacked the so-called "agile" team and they set priorities and dates - but have no expertise in software engineering nor the software development life cycle (SDLC). Dates are commonly missed because of their decisions, but they rarely take responsibility. I is truly sad to see how these places have BAs and QAs running the SDLC, but with little to no knowledge of how software engineering works. Developers, to them, are basically code monkeys.
PM: We need this by Tuesday
Development: Okay, here you go
PM: When I asked for x, I actually meant y
Development: No worries - here's the new version
PM: Thanks. Oh, by the way, any chance we could have z?
Development: Yes, here you go.
PM: Cool. Now I come to think of it, could you just maybe tweak x so that it does something unrecognisable from the original x.
Development: But we weren't going with x, would you rather tweak y?
PM: No, forget that, let's redefine z
Development: Okay, z now does pretty much what x used to do
PM: Ah, that's good. Not sure we need it any more, though.
Development: Fine, it's on UAT if you change your mind.
[3 MONTHS LATER]
PM: Have we still got that thingymajig?
Development: Yes, it's still there on UAT.
PM: Cool. Can we get it live by next month?
Development: Yes, as long as you can get someone to test it.
PM: I'll get back to you on that. Did you ever manage to get it to make a cup of tea when it's done? I know we didn't ask for that but it would be a pretty nifty feature.
[2 YEARS LATER]
PM: We tested that software. We had to fail it, I'm afraid - we didn't get that cup of tea. The stuff it did do might have been right, I can't quite remember the requirement it was that long ago.
I have been programming professionally since 1978, and I could not agree more. Projects take on a life of their own, and those answering yes are kidding themselves. "Project Creep" and ridiculously vague "requirements" are the driving forces in my experience.
It's a random chance Universe and we are all out there surfing waves of probability...
Although no deliver dates, I generally get it done faster than expected.
This, however, might be a result of the really lousy delivery record for any number of the overseas outsourced projects that take far too long and perform far too poorly.
A second caveat is that somehow I've been given a blank check with respect to which project I do when. Clarifying, I often have several sitting in line - I almost always make the decision of priorities (bug > new > tweak) - but that's not the whole story.
There's also (owner/very Sr. Mgmt > nice people > neutrals/new faces > ass).
How this came about is a mystery - although making stuff that works correctly, for a long time, and is smoothly upgradable may have helped my cause.
All of our projects are internal. Presently our only delay is getting the users to complete UAT and regression.
So any delays that happen now are not due to use delivering late.
That is true for most of my work at the present time. However, it doesn't stop the user/customer from claiming the project was delivered behind schedule. They just leave out the part where it took them 3 weeks to even get around to testing, then decided that a feature they forgot to mention should be considered a "bug" because it wasn't included.
I hear you on that one, but then the parent company mentored our department a bit and now the people that make decisions have to sit around the table every 2 weeks and let the project sponsor know why it's late.
and the project sponsor is senior figure and for our main application it is run by our General Manager, who is also a divisional head in the parent company, so the waffle is then removed
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
Last Visit: 31-Dec-99 19:00 Last Update: 31-Jan-23 10:44