Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to John D Carmack and Random Acts of IT Project Management with appropriate and specific direction to the original content.

Tech

Posts Tagged ‘SDLC’

One of the more useful items in the Agile arsenal is the daily stand-up meeting. Naturally, if you are using Scrum, then the meeting is called a “daily Scrum meeting”. Having everyone stand encourages the meeting to be short. The ideal meeting should be ten minutes, but never over 15. If issues come up that cannot be resolved in that time frame, then a longer meeting may be scheduled with only the necessary participants.

How would you like an overview of Scrum in the amount of time that a daily Scrum meeting would last? Well, Hamid Shojaee posted “Learn SCRUM in Under 10 Minutes (HD) by @hamids” in ProjectCorner that does just that. The video is actually 8 minutes long and packed full of information that a novice will find handy.

There seems to be an unofficial theme this week of pointing out some fallible lines of thinking. I honestly didn’t plan it to come out this way, but sometimes patterns emerge before we become cognizant of them.

This week started off talking about “What is Agile Project Management?” Basically, describing Agile as a “methodology” doesn’t make much sense. Rather, it is an umbrella, or better a philosophy, underneath of which are some methodologies (scrum, XP, etc.).

Tuesday, I pointed out some faulty beliefs that point to a lack of proper priorities in “Where Is the Time?”

Wednesday’s post was on “Web 3.0, Anyone?” While the technology is emerging to do some really cool stuff, a lot of it just isn’t here yet. Somehow, though, I saw job postings for people “experienced in Web 3.0”.

Thursday’s post was about “Don’t Make It Hard!” This was mainly about how people can make things harder than they need to. It also scratched the surface of how a team’s reaction can make the problems worse. Finally, I used the example that bore the topic of implementation and how it isn’t implementation that is hard, but rather it is the sequence of steps and missteps that lead up to it that are hard.

It seems appropriate today to come full circle and examine the waterfall method. Just like the others this week, I read something that made me go “No!” out loud.

In case you are new around here, let me summarize from my own Associated Content article on “Agile Project Management” just how I feel about the waterfall:

Like a dinosaur, the waterfall methodology is large, cumbersome and slow. If it trips and falls, it makes a very large noise. Unfortunately, the waterfall is not like a dinosaur, as the latter is extinct.

So, what do you think went through my mind when I read that Steve McConnell of all people wrote about a company that “embraced Extreme Programming (XP) as the development approach”. Yet:

Development went on for about two years. While the team was being highly responsive to customer input, that wasn’t good enough. The cumulative total of its work was not converging to anything resembling a saleable product. Eventually the company concluded that the team was never going to produce a product, at which point most of the 200 people were laid off and the company reported a $50 million loss on the project.

The real tip-off here is that nothing was “converging” to make a “saleable product”. Say what?

Sometimes life is a lot like Alice in Wonderland (or at least the Disney version).

Alice: Would you tell me, please, which way I ought to go from here?

Cheshire Cat: That depends a good deal on where you want to get to.

Alice: I don’t much care where–

Cheshire Cat: Then it doesn’t matter which way you go.

Alice: –so long as I get somewhere.

Cheshire Cat: Oh, you’re sure to do that, if you only walk long enough.

On George Dinwiddie’s Blog, Dinwiddie posted an article “Agility and Predictability”, where he addresses the predictability factor. However, I want to focus on the fact that the product owner in the above example “didn’t have a vision for a salable product.”

I hope many of you got the chance to attend the webinar yesterday on “Agile Requirements (Not an Oxymoron)” by Ellen Gottesdiener of EBG Consulting. She pointed out you need: A “now-view” at the iteration level, a “pre-view” at the release level and a “big-view” at the product level. It is debatable if the team even had a release level view in McConnell’s example, but it is certain that they did not have a “big-view” of the end product.

Agile is no excuse for not knowing where you are going. Agile won’t help you get there if you don’t know the destination. The methodology cannot help you if you are simply wandering around Wonderland.

In fact, Agile is not a cure-all by any means. If anything, Agile will tend to uncover organizational and procedural deficiencies much sooner than the waterfall method. However, regardless of the methodology, if an organization buries its head in the sand, it won’t work out. One of the main features of Agile is evaluating performance at the end of a sprint. Like any evaluation, though, individuals and teams can gloss over and politic, or they can admit mistakes and make adjustments.

Waterfall will cover up mistakes until the very end, when suddenly, everyone realizes the project is behind schedule. It’s almost inevitable on any project of any complexity or of any significant size. So, yeah, waterfall is more “predictable”. It is more predictable that it will fail!

When does waterfall work? Waterfall works when the results and processes to get there are well known. If you are setting up servers just like the last 20 you did in the last quarter, then the waterfall approach will most likely be suitable. When the chance of randomness is very low, then it is much easier to project the end.

Waterfall also works when the duration is shorter than 4 weeks (not including project management paperwork).

IOW, waterfall sometimes works when the one iteration is about the same size as recommended for one or two Agile sprints!

When you think about that, you think about how there is no real feedback until the end of the cycle, you think about how little testing is done until the end and you think about “progressive elaboration”, then why would you tie your cart to the waterfall horse?

The term “Agile” has become such a buzzword that it has lost its meaning in the current development environment. To paraphrase an old joke, if you ask 4 IT managers what Agile is, you’ll get 5 different answers. Some will interchange the usage of “Scrum” and “Agile”, but is that the correct usage of these terms? What is the difference between “Scrum”, “XP” and “Agile”?

Failure is instructive. Most of us have an instinctive aversion to discussing weakness, based on concerns that criticism may hurt our pride, reputation, and so on. While I deeply respect these sensitivities, fear creates an environment where repeated cycles of failure can manifest. Breaking this cycle requires understanding the source of problems followed by developing solutions to address them.

Failure causes you to learn. Hopefully, success does as well. Humans have an amazing capacity to learn, and we should do so at every opportunity. If we do not learn, we do not improve professionally or grow personally.

Teams and even companies can learn as well. That’s why Bowers’ article is so important. If teams and companies cannot face the facts and learn, then they never improve. Projects will continue to fail.

A thorough “lessons learned” or “after action” review is a must. The US Army has a tradition of sending soldiers on field exercises and then holding after action reviews afterwards to grade themselves. Self-reflection is the key to improvement.

That’s why in the long run requirements gathering just plain is not as important! Why? Because a thorough lessons learned review will uncover it as a weakness and make recommendations to fix the problem. If you do lessons learned poorly or not at all, you will never know if your requirements gathering is any good or not!

What if you had a project to create a product, it was done on time and under budget, it was delivered and the customer never complained. Was the project a success? How do you know?

There is a saying that for every customer that complains, there are 9 others who have the same problem but do not complain. It could be because they are too busy or too tired, or maybe they don’t know who to complain to. Just because no one complains does not mean the project was a success. Again, you have to gather data after the main portions of the project have been completed.

The fact that I’ve changed my mind about “requirements gathering” is proof I’m not too old to learn. 🙂