Waterfolly la, la la la la
Deck the halls with specifications
Water folly lolly la, la la la la
Wad up the changed versions for decorations
Water folly la, la la la la
Don we now our passing deadlines
Waterfall folly la, la la la
Tripping bugs like aging landmines
Wateryfolly la, la la la la
Ok, I kid. In all seriousness, I've learned some great things going from Agile to Waterfall that I'd like to share. Scrum has a few problems that I'd like to see addressed. One is that the PO job is too hard! On the project I'm working on, we have a great team of Business and Functional Analysts. They are working with end users to design something that works overall WITH agreement and flexibility for change in the future. Because they demo the creation in Proof of Concept, and because there is User Acceptance Testing, there is more customer interaction than the Agile team I worked on. Also, instead of the product owner being the one who understands, we are all responsible for understanding and building/testing/designing what suits the business need. The part where someone communicates well with the users is deemphasized in the way Agile is often implemented, especially with Scrum.
So far the best part of working on this team is my stress level. I'm not working every weekend and until 1am. I don't feel on the verge of tears or like I'm working with an axe over my head. I have a reasonable amount of time to do things. The schedule is MORE agile than my agile project was. I do not miss the daily Scrum meetings at all. I meet up with the analysts when I have questions, and in this way communication is better than it was on my agile team.
If I could change one thing, it would be the specs. Rather than endless pages of documentation, we'd do quick presentations, diagrams, and demos. The recordings in video would be the working spec. It is getting the walk through and agreement that matters, not the format. I also notice that business people read even less than we do. No one making business decisions want to read a 150 page technical spec. I like the agile approach better.
I've realized I want to work on a team with great communication, a flatish org structure, and to have trust. I'd prefer a place who doesn't do "initiatives" and instead is focused on building great software (what works over what the process is). I don't think scrum or waterfall are good answers. In fact, I think scrum as practiced has little to do with the agile manifesto.
Water folly lolly la, la la la la
Wad up the changed versions for decorations
Water folly la, la la la la
Don we now our passing deadlines
Waterfall folly la, la la la
Tripping bugs like aging landmines
Wateryfolly la, la la la la
Ok, I kid. In all seriousness, I've learned some great things going from Agile to Waterfall that I'd like to share. Scrum has a few problems that I'd like to see addressed. One is that the PO job is too hard! On the project I'm working on, we have a great team of Business and Functional Analysts. They are working with end users to design something that works overall WITH agreement and flexibility for change in the future. Because they demo the creation in Proof of Concept, and because there is User Acceptance Testing, there is more customer interaction than the Agile team I worked on. Also, instead of the product owner being the one who understands, we are all responsible for understanding and building/testing/designing what suits the business need. The part where someone communicates well with the users is deemphasized in the way Agile is often implemented, especially with Scrum.
So far the best part of working on this team is my stress level. I'm not working every weekend and until 1am. I don't feel on the verge of tears or like I'm working with an axe over my head. I have a reasonable amount of time to do things. The schedule is MORE agile than my agile project was. I do not miss the daily Scrum meetings at all. I meet up with the analysts when I have questions, and in this way communication is better than it was on my agile team.
If I could change one thing, it would be the specs. Rather than endless pages of documentation, we'd do quick presentations, diagrams, and demos. The recordings in video would be the working spec. It is getting the walk through and agreement that matters, not the format. I also notice that business people read even less than we do. No one making business decisions want to read a 150 page technical spec. I like the agile approach better.
I've realized I want to work on a team with great communication, a flatish org structure, and to have trust. I'd prefer a place who doesn't do "initiatives" and instead is focused on building great software (what works over what the process is). I don't think scrum or waterfall are good answers. In fact, I think scrum as practiced has little to do with the agile manifesto.
Posted by Testy Redhead at 16 Dec 2010 
Categories: Ideas, company, Working with Others, Career Development, Subjective Data, user, usability, strategy, Engineers, Collaboration, Software Testing, Testing, Learning, Career, Meetings, test methdology, Software, Growth, Process, Research, ethics, consulting, agile, testing ideas, Development, communication, Test methodology, programming, User Experience, test documentation, test strategy, language, TEAMS, Leadership, Management Skills, Methodology
Categories: Ideas, company, Working with Others, Career Development, Subjective Data, user, usability, strategy, Engineers, Collaboration, Software Testing, Testing, Learning, Career, Meetings, test methdology, Software, Growth, Process, Research, ethics, consulting, agile, testing ideas, Development, communication, Test methodology, programming, User Experience, test documentation, test strategy, language, TEAMS, Leadership, Management Skills, Methodology
Neat post Lanette, but I have a different response when I hear about your previous 'agile' project -- I want to know who coached the team that 'transitioned' to Scrum, and if they stuck around long enough to see what a mess the project had become in their name.
The only term that comes to mind is "you're doing it wrong", or maybe "we tried baseball, and it didn't work": http://xprogramming.com/articles/jatbaseball/
Reply to this
Ever heard of that Ken Schwaber guy? Well, I can't blame him, as I thought his Scrum Master training was quite good at the time. There were some higherups who didn't quite grasp the Agile Manifesto thing. There were some things quite RIGHT that happened on the team. I really enjoyed pairing with the developer who was willing.
I think the retrospectives were worthless, as was every "post mortem" I've ever been involved with. That is where we vent, take lists, and nothing ever changes. I prefer to use that time celebrating if nothing is going to come of it. I've always felt tricked by retrospectives. I feel talked down to, like somehow companies feel if we "let it all out" we won't notice they aren't changing anything.
I'm working on a small side project, which I'm hoping can restore my optimism. I strongly believe in the Agile manifesto. I just think it has some core incompatability with capitolism that no one is willing to talk about. Money talks,..and well, manifestos walk because money is first. At least in most of the world and in America.
Reply to this
Given what you like and don't like about each, and what you know you are looking for, I think you should try and get on an XP team.
Reply to this
I like this post, it highlights that people are more important than the process.
I have never worked more "agile" than in a Waterfall project 10 years ago.
As for the "we tried baseball, and it didn't work" argument, you need to understand why you are doing things.
If we are 5 musicians that want to entertain people, baseball isn't a good idea.
Reply to this