Agile Software development and ASD

Post Reply New Topic

I have two of four parts on Agile Software Development and ASD out on my blog if anyone is interested:

Part One

Part Two

I'll try and read those later but speaking as an aspie with long experience in the software industry, the biggest problem with anybody and agile development is ACTUALLY DOING IT.

The place i work, two years ago, went through an "Everybody agile all the time everything! OR ELSE!" campaign from upper management.

We are still rigidly waterfall.

Since I'm in QA, that means i'm the rocks at the bottom of the waterfall getting pummeled.

we have "scrums" that resemble a homeroom roll call and "elaboration" that happens during the first sprint, and hard delivery dates, and a last sprint that turns into a death march. It's wonderful i tell you.

The only thing that's totally different from before is that nobody can say for sure what the requirements were for the last release.

I think a big factor is upper management's perception of the level of ease of micromanagement that scrums give them but they still fear allowing peons to make decisions.

Thing is, what many rarely realize, is that agile development isn't always the answer, and in many projects (as per my experience) it cannot be used as intended for the most part. The only proper excuse to implement agile development is if management wants to keep tabs on a given project, the point is having a workable program that can be tested and built upon throughout the dev process.



As said, depends on what kind of projects you do, agile development rarely works with smaller projects and projects where the team is forced to fumble around somewhat blindly...

IMO agile development is overly complicated. I've always just seen it as; make feature XYZ, make sure it works as it should before deadline and have a status meeting regularly. Main problem is, if used inappropriately, the team inevitably cranks out slow, crappy code that is hard to rewrite or customize.

I have wondered how many Agile implementations are a business type grasping at a buzzword. In the current company I am at everyone is on several scrum teams some of which have their standup being you walk into a room, speak to a manager while standing up for five minutes and then leave.

I think the product i work on is not a good candidate for agile.

It is large and complex and has been under development for almost 17 years.

We have features that nobody is quite sure who asked for them or who might have used them once.

Oh, and four or five programming technologies are involved.

About the blogs... nice to read. I just got involved with Agile methods recently. Problem is the adherence of the company to the method, and to be honest.... they frak it up like every other method they use. I recognize especially the 'eagerness' of management (half-hearted commitment)

I see some big advantages, having the people in one place and not needing to travel a lot and a fixed desk for me again. The team is also more standard, that makes it a bit easier to get used to people.

A disadvantage are the changed roles and uncertainty in them. Now other people start designing, and I am not sure if my careful planned ideas will be used. But as always there are enough other things coming in between and it will probably end up like it always did... that I can do my job and make a lot of hours and get nice pay raises because of my efforts to save the project.


@blauSamstag:
Your system sounds complex with a lot of unused code and functionality. I have worked on something similar. We started revising the system in parts. First looking at the original screens, describing the features and talking with business and functional designers to get the bare functionality. That was built into new screens. That was a few years ago, but I think Agile could be used since the screens were relatively small. In this case there was some new functionality, if there is not to be new functionality waterfall can be preferable.

I also rewrote a few batch programs. That was fun. First stripping out the unused code and functionality. Then describing the flow and later rewriting the flow and part of the code. Those were small programs, so they could be done one-by-one.

@Asterisp, it's big with a lot of features and unfortunately a lot of the users got burned by the previous management regime and don't really communicate with us anymore.

There are features that probably nobody uses because whoever asked for them didn't really know what they needed. Or maybe it was tied to some policy that no longer exists.

I am wary of saying too much about work online, but if it helps illustrate the nature of gordian knot, it's in the field of regulatory compliance.

We have recently started implementing major feature changes as new screens developed with a more modern technology than the toolkit that was used to develop them previously, which has presented more roadblocks than anyone predicted.

Here is Part Three

I've enjoyed reading this so far. My only experience with agile software development was a semester long team programming project I had to do. We had to use the scrum methodology and a few weeks in I just wanted to rip my hair out. The team I was on wasn't very organized and I think that was a big part of the frustration I had with the experience. I found that there were many times that I would have to write extra code to get things to work that I knew would be removed in the next sprint when new features were added. I ended up writing a report about how poor/frustrating I thought scrum/agile methods were and ended up kind of getting lectured by the professor afterwards about how "you need to learn to be more flexible" and "this is what it will be like in the real world".

Anyway I just wanted to say I like what you've written so far and it is interesting to read this and compare it to my brief experience with agile.

Documentation is a good point. Most of my documentation was written with incident analysis of existing software. So I wrote the difficult and special things in a document and expanded it when needed. Advantage is that it only contains useful stuff. Downside is, it takes a lot of time when you did not write it yourself.

My new documentation is a bit 'lean' like that, only the parts I find useful and when somebody wants more... well he can expand it.

I am a software developer, (well, unemployed the moment) but do not have experience with "Agile" methods. But I have to say I am pretty pessimistic about the ideas. Seems like the more agile the development process is, the more communication has to go on, the more competent the developers must be. In my experience there is always a lack of communication and competence unless you have a small group of superstars in the same cubicle.

For someone with ASD, agile methods sound good, because it could prevent such a person from going off into their own world. But realistically if there is going to be poorly-defined goals and dismissals of people concerns, then, then it will be hard for everyone.

Development methods have to take into account that mistakes will be made and there will be conflicts. Not just bugs, but situations like where the customer is the enemy. Sometimes people actively avoid communication or are in competition with each other. That is why processes and tools and documentation are put into place.

Sound slike ti can be rather cackhanded - I'm trained in support, not dev, and did my computing degree back in the 90s...

But I DO recall crappy releases making it into production without enough documentation.. and trying to triage when, say, logs werent' written...

About to be made redundant (restructure/outsource/offshore) - so looks like I'll need to just get my MCSE and other sysadmin quals to crosstrain from my 10 years Lotus Notes and 10 years Capacity Planning experience...

Also slowly getting my health back from almost dying in 2011 and having cellulitis between 2011 and 2016/2017...

Great blog posts, OP!

I feel very ambivalent about agile methodologies. I've worked in roughly equal waterfall / agile projects. I think that a lot of developers and managers don't do their research about when to use which method, or how to successfully run an agile project. Often, they just concentrate on scrums and sprints, but forget about all of the other parts of the product lifecycle: requirements gathering, design, testing... These parts of the lifecycle tend to be invisible to developers and managers coming from that background.

The biggest issues I see is that projects just jump in without getting business requirements, talking to customer base or doing market research and not creating at least a starting proposition of a design. They just start building from the first scrum.

There is a new idea out there that I believe is causing even worse issues -- MVP Minimum viable product. It's like a new catchphrase and I really do not agree it is a good approach. I believe in having some sort of product vision, not just bumbling along making little bits of functionality in isolation.

Personally I favor neither pure Waterfall nor pure Agile, but a mix of the two. Exactly what mix is most appropriate varies with the type of business, it seems to me. For example, the needs of a large, well-established corporate government contractor will be very different from the needs of a small consumer-oriented startup.

I work as part of a self-employed two-person team of programmers. Our main client is a small medical lab that does remote heart monitoring.


Ugh. Doesn't sound good.


Hmmm, it seems to me that MVP, or something like it, is an unavoidable necessity if you're working for a small startup. Problem is, there's no way to know for sure what your potential customers really want until they actually start using some version of your product. Preliminary market research, before doing anything at all, is helpful but not enough.

Another problem, at least with consumer-oriented stuff, is that the market moves quickly. In the time it takes to fully implement a complete grand vision, the market may have changed dramatically.