Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Thursday, November 22, 2018

, ,

The Anatomy of Agile Software Development Methodology

Share

There is something kind of funny going on right now that I can’t help but notice. Agile development has real traction after being around for over 15 years and various flavors of the agile theory have manifested as shrink-wrapped development methodologies. I would argue that there is an attempt to eclipse the role of the project manager with that of the scrum master.



Big Mistake or Noteworthy for Agile Movement

I happen to think this is a big mistake in most cases but could be viable in a small instance of circumstances. Like PMI created the PMP, the Agile movement is producing its own collateral materials. This is not bad, but it is noteworthy. It is a little industry now, with substantive artifacts, proven success, and mention in mainstream journals, etc.  I am grateful for this, as I am grateful for anything that makes developing software more disciplined.

Actual managers and salespeople, like the one pictured to the right, like to tell each other that their development team is “doing Agile” even if they all they know about development are that developers do it. I think by now, because of all the questions that the notion of agile development mandates, they know better than to think it means people are lithe and quick, jumping over hurdles as they code.

Agile based Team



Still, you will notice that the manager in question seems to be insecure about something. Look at the eyebrows, notice the uneven, forced grin. He is faking it. Clearly. I happen to know this fellow, and he is not thinking about agile teams, but I owe him some publicity at the very least after all he has done for me.
Anyhow, there is Agile with a capital A. Wittgenstein and Russell would refer to this as a Universal and note that they do not exist in actuality. All that exists are manifestations of Agile; agile practices that are in play are real, while Agile theory remains an amorphous object of study, though, and guest speakers.
Recently, I heard someone on Twitter say that this other person’s team was not an agile team because they did not use story points. This is just an example, and there are others. I have been told that a team I worked with was not agile because they did not have 2 week long sprints. We did UAT every 5 days.

Why User Acceptance Testing



There is a reason we did UAT every 5 days, and there was a reason, I am sure, that the Tweeter did not use story points. The fact is, I would have to explain the notion of story points to the more “mature” developers who are used to coding against a thick spec and more often than not, the learning curve comes at an inopportune time.

This is especially true at small software development companies who cannot send their development team to training. So, we have daily stand-up meetings and do the whole “What did you do, what are you doing, what’s in your way” thing. I tend to *expect* that scrum masters know that asking the questions is not enough and that they are there to grease the wheels where they can and remove obstacles if possible. Maybe they would even recognize patterns if they are truly sharp. However, this is also more theory than practice.

 I have seen scrum masters behave in a way other than they were taught when they paid for their ScrumMaster certificate. In some cases, the developers were so on the ball that they removed their own obstacles. Valid? Sure. They cranked out releases on a regular basis and had happy clients, useless PMs that they ignored, and did what was almost development ballet. As to my UAT every 5 days, it was in the contract. Do any of these things mean that our teams are not agile?
No. There is no litmus test. There are best practices, but even they are subject to context and interpretation.

Should Move toward Agile?

Agile development is based on a manifesto and foremost, people over process. Change hurts, and moving towards Agile can be painful, but the Barely Good Enough principle applies here, I think. While Ambler may have taken it a little far with the Agile Unified Process, I do like the more practical idea that what is just barely enough is actually optimal.
How many million dollar projects will not have a CEO or Manager among the stakeholders who will expect or even demand to see an old-school GANTT chart? Most of the ones I have worked with do in fact want this. Now, regardless of what our development methodology, I can deliver artifacts that are required. Agile would tell me that this is useless and waste. Not true. The relationships (people) is at least as important as the process. Again, building software services is not just about sitting devs at their desks, having daily meetings, and forming burn-down charts, velocity graphs, and backlogs. It is amorphous, involving everyone from the insecure manager mentioned at the beginning of this post to the happy, secure, million-dollar smile manager pictured to the right.

Practice Agility

My point is this: anything that adds value is worth it. Anything that improves without causing undue pain is worth exploring. If *only* doing a daily standup enforces accountability yet nobody has heard of a sprint, what is wrong with that? It is a place to start, and it is inspired by Agile, which is inspired in truth by what is practical when dealing with the slippery devil that software development can be. I know when my wife goes out, I am calling her every hour (I am getting better). This is because I know there are lots of variables out there that need to be taken into account and checking in never hurts (part of why I am getting better is because she actually *did* hurt me with a frying pan after I bugged her all night, but I digress again).
Don’t try to be Agile. Actually, practice agility. Study Agile methods, but practice agile techniques. The CMMI for Agile environments is interesting in that it doesn’t appear to assume a particular flavor of Agile. I am not a fan of XP at all, although I have worked with developers that rock with peer programming. That was them, and part of my toolbox is a lens that lets me recognize value. I let them rock. Of course. It was cool as can be and I learned another face of Agile. I love being around people who know more than me and are smarter than me. It isn’t usually hard. Still, the point is that no one way is right and no one way is complete or incomplete. Everything is in context.

Spread the word and share:

0 nhận xét:

Post a Comment