Random Acts of IT Project Management

Project Management for Information Technology

Archive for the ‘Agile’ Category

Railing Against Project Bureaucrats

Posted by iammarchhare on 3 September 2009

Being a project manager is walking a fine line.  Many mistake project management for doing EVM, making a schedule, filling out a charter, and so on.  These are functions of a PM, but they are not the most important.

TechRepublic posted “Managing innovative projects: Don’t mistake the map for the journey” by Rick Freedman.  Freeman writes about these paper pushers who “manage” projects:

When I teach project management, I often draw a distinction between project managers and project bureaucrats. We’ve all had encounters with project managers who turned into bureaucrats. Project bureaucrats are more interested in ensuring that every step of the methodology is applied and every line of every form is filled in than in what’s actually happening on the ground. On the other hand, it’s common to meet project managers who apply minimal project methodology, yet, through their expert use of relationships and personal interactions, always seem to know exactly where the project stands.

He goes on to give an excellent example of a project failure.  That is, it was a bureaucratic failure.  Yet, the product was an ultimate success.  The product was the film Titanic.

So, how does he view being innovative while still maintaining project discipline?  You’ll need to read his article to find out.

Advertisements

Posted in Agile, Leadership, PM Basics | Tagged: , , , , , , | 1 Comment »

What Is Agile Software Development?

Posted by iammarchhare on 2 September 2009

One of the best explanations I’ve seen yet of Agile is the article “10 Key Principles of Agile Software Development” over all All About Agile.  Not only does the author give a good summary of some key concepts, but also some of the variations, including the original DSDM.

Enjoy!

Posted in Agile, Software | Tagged: , , , | Comments Off on What Is Agile Software Development?

Learn Scrum in the Amount of Time a Stand-Up Meeting Lasts

Posted by iammarchhare on 7 August 2009

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.

Posted in Agile | Tagged: , , , , , , , , , , | Comments Off on Learn Scrum in the Amount of Time a Stand-Up Meeting Lasts

Tips For Agile Project Planning and Estimating

Posted by iammarchhare on 29 July 2009

I came across the Hub Tech Insider blog article “Twelve Tips for Agile Project Planning and Estimating”, and I’m pretty impressed.  I’m going to check out other articles offered on the blog as well.  However, there seems to be a short series of articles, and then it ends, unfortunately.

The first tip is also one I consider to be one of, if not the, most crucial:

1. Keep everyone on the team involved – Buy-In, or real commitment, from every member of he project team is vital to the success of the project. For example, the estimation of the project is an activity that should involve all members of the project team, while only very particular tasks such as prioritization of requirements should be the primary responsibility of the product owner or an individual project team member. The more work is shared by the team, the more victories the team will have to share.

From my experience, constant communication between team members is at the heart of Agile.  That’s why Scrum is so adamant about co-location for team members.

Anyhow, I hope that Hub Tech Insider continues on.

Posted in Agile | Tagged: , , , | Comments Off on Tips For Agile Project Planning and Estimating

Waterfall vs Agile

Posted by iammarchhare on 21 July 2009

I frequently like to compare waterfall and Agile methodologies, or perhaps mindsets would be a better term.  Yet, I realize that my descriptions are colored a lot by my own experiences.  So, I do like to point you to other sources from time to time that take a different approach or describe the differences in other terms.  I hope that gives the reader a more well-rounded look at things.

Robert Merrill on 18 February 2009 posted “A Tale of two processes”.  He starts out describing “How to create software” by writing:

Let’s create some software value. It’s very simple.

  • You tell the programmers what you want the software to do
  • They create it
  • You verify that it does what it’s supposed to
  • You let people start using it, and out pours the value.

Sounds simple, right?  Well, in a nutshell, he has summed up how waterfall is supposed to work.

I think the contrast is interesting and a worthwhile read.  You can read his article here.

Posted in Agile, SDLC, Software, Waterfall | Tagged: , , , , | Comments Off on Waterfall vs Agile

Agile Development Principles and Pareto’s Law

Posted by iammarchhare on 19 June 2009

Helium writer Kelly Waters wrote an article on “Agile development principles explained”.  I’m going to confess that I often read others’ articles and then write my own version (Helium has authors compete for ratings under the article’s title) because I just don’t like the #1 article.  I’m not going to try to top Waters’ article, although I would have liked to have seen more in it.  It is hard sometimes to strike the right balance between too much and too little information.  In my opinion, though, this particular article should have been named “Pareto’s Law” instead.

Posted in Agile | Tagged: , , , , , | Comments Off on Agile Development Principles and Pareto’s Law

Use Cases and User Stories – Just Degrees of Difference?

Posted by iammarchhare on 26 May 2009

What is the difference between doing use cases and doing user stories?  Use cases are UML methods of bridging user requirements with a system.  User stories are an Agile way of doing the same thing.  However, throw into the mix that there are formal and informal use cases as well as a use case brief, and you have a potentially confusing situation.

What are the differences between these, then?  Well, Scott Sehlhorst at the Tyner Blain blog tries to tackle this question.  Perhaps they are really just different points on a continuum of overhead and detail.  Throw in the level of reader trust, and you can graph these different items.  “User Stories and Use Cases” is an interesting read.

Posted in Agile, Requirements | Tagged: , , , , , , | 1 Comment »

Scrum

Posted by iammarchhare on 15 May 2009

I have had to introduce Agile processes and techniques into various situations and environments, but I’ve never had the opportunity to go fully scrum.  That’s OK, as a methodology is just a tool to get you where you are going, but it would have been nice to actually go through an entire project using all of the core practices at least once.

Anyhow, I know there is a lot I can learn about it as a result.  If you are as unfamiliar with full-blown scrum as I am, I suggest you check out “Am I, or Am I Not, Using Scrum?” over at Scrum Alliance.

Posted in Agile, SDLC | Tagged: , , , , , | Comments Off on Scrum

The Beast Called “Waterfall”

Posted by iammarchhare on 1 May 2009

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.

~ McConnell, Steve.  (29 July 2008).  Agile Software: Business Impact and Business Benefits.  Retrieved 29 April 2009, from http://forums.construx.com/blogs/stevemcc/archive/2008/07/29/agile-software-business-impact-and-business-benefits.aspx.

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?

Posted in Agile, PMBOK, SDLC | Tagged: , , , , , , , , , , , , , | Comments Off on The Beast Called “Waterfall”

What is Agile Project Management?

Posted by iammarchhare on 27 April 2009

When is a methodology not a methodology?

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”?

Read more about Agile Project Management at Associated Content.

Posted in Agile, PM Basics, SDLC | Tagged: , , , , , , , , , , | 1 Comment »