PMI Atlanta Chapter Agile Local Interest Group

Last night was the inaugural meeting of the PMI Atlanta Chapter Agile Local Interest Group. This group will meet on the third Tuesday of every month to provide Agile speakers and events to support the Agile Project Management community. I am heading up the LIG with a great group of volunteers including Phyllis St John – who has been instrumental in getting the LIG up and running. Cox Enterprises provided that space and John Kosar from CCCI sponsored dinner and coordinated the space.

I was the presenter last night. I did an introduction to the roots of Agile and talked about Knowledge Domains around the new PMI Agile Certification.

Thanks to everyone who attended and provided input on what you would like to see from the LIG.

Mike Cottmeyer will be presenting next month. I will post details here on the location as we get that sorted out.

4 Responses to “PMI Atlanta Chapter Agile Local Interest Group”

  1. Glen B Alleman says on :


    Some comments on the nice presentation. I’m speaking at an upcoming Defense conference on the use of Agile in DoD IT procurement. I’ve started a collection of “red herring” presentations that should be “outed” before the decision makers at the DoD do.

    ▪ Page 7 seems to make statements that are missing evidence. Scientific management in the development of manned space flight is low job satisfaction, de-skilling and dehumanizing? How about some domain and context.

    ▪ Page 8 – plan all work upfront ignores the mandated rolling wave and Planning Package paradigm mandated in large programs.

    ▪ Page 9 – got any domain and context for these claims.

    ▪ Page 10 – did you actually read the Royce paper? he says on 329 “I believe in this concept (waterfall), but the implementation described above is risky and invites failure.”

    ▪ Page 11 – more unsubstantiated statements.

    ▪ Page 12 – rigorous adherence to a detailed plan is simply BS on any real program. It may be BAD management, but it’s just that BAD management. Not found on any credible enterprise program.

    I don’t understand the need to use this approach. No domain, no context, broad overstated “red herrings,” mostly anecdotal. I would invite you to come visit our large software intensive programs, with rolling waves, incremental Work Packages with “emergent” requirements (astronauts change their needs every release or so).

    Applying agile “inside” Plan Driven programs is done at NASA and other software intensive programs.

  2. Dennis Stevens says on :


    We have had this discussion before. I still don’t understand what you find problematic with the approach. I point out how historic management theory – taken to an extreme – can be a problem in organizations. I understand that responsible project management happens on a continuum between adaptive and predictive and that responsible project management would never advocate for any what I put up. I understand that the Project Management literature doesn’t advocate for any of these practices. I understand that you live in a place where responsible project management is practiced by inquiring professionals every day.

    However, the state of the literature does not match the state of practice. I see organizations that glue the Business, Business Analysis, Development, Quality Assurance, Production, and Support together through detailed document driven processes, an explicit separation of actual collaboration between member of these groups, and a focus on complex tools that are delivering local optimization with no focus on the flow of value and the usefulness of the artifacts produced to members downstream. I see projects every day where project schedules with detailed task lists and precise time estimates are used to drive execution with no respect for the actual variance in the work. I see PMO’s with SDLC’s that dictate waterfall approaches with distant QA and no accounting for remediation. I get that the literature and seasoned professionals would never advocate for this approach – but I SEE IT PRACTICED IN REAL BUSINESSES EVERY DAY.

    It turns out that management theory has advanced in the last 100 years – particularly in dealing with experts and knowledge work. Trying to apply 100 year management science to these projects destroys value for the business and is dehumanizing to the members of the organization. In my presentation I point this out. I then point out how over the last 50 years we have been doing it better. I show how a decade ago the Agile Manifesto was a response to this gap between irresponsible practice (with roots in outdated management theory) and the state of practice. I go on to show how you can be value driven, collaborative, adaptive, and improving while still being predictable. I emphasize that “The practices on the right” are still important – but we need to give sufficient attention to the practices on the left.

    There is nothing red herring in my presentation. Management theory has advanced. A lot of the common sense that drives the state of practice is based on these old ways. The old ways are not sufficient. The Agile Manifesto was a tipping point in coalescing this. We have ways to work that are pretty well recognized. Learn the new way. When I go through my presentation I get people nodding their heads – realizing the folly of the the extremes and recognizing the impact the application of these extremes has on their daily life and their ability to deliver value. When I point out that Agile doesn’t mean irresponsible, they find room to embrace it and find safety in the realization that they can manage responsibly with different practices.

    Page 7. How many of Taylor’s plants unionized after his work was implemented? How many of them fell back from his approach to scientific management?
    Page 8. And chocolate and peanut butter go well together. Plan driven is valuable when done right in the right context – where do I suggest you should not have any planning? I suggest you need to take variation into account in planning and separate planning from execution.
    Page 9. Really Glen. Every project, every day, on every project. How about driving to work?
    Page 10. I point out that Waterfall was written by Royce as a red herring and that people that implement his model must have gotten bored before finishing the paper. BUT I SEE IT IN FORMAL SDLC IN BUSINESSES EVERY DAY.
    Page 11. Really Glen. You have a lot of experience backloading all the QA on your projects. I use Royces paper to defend my claim that this is risky and invites failure.
    Page 12. That is exactly my point. It is bad management. BUT I SEE IT IN PRACTICE IN REAL BUSINESSES EVERY DAY.

    The need to use this approach is THAT I SEE IT IN PRACTICE IN REAL BUSINESSES EVERY DAY. I would love to see you run project responsible. I can run them responsibly too.

    I have tremendous respect for you, your contribution to the industry, and your experience. But, I think it is a red herring, and irresponsible, to pretend that the state of practice is anywhere near the literature. Include my stuff as red herring work that should be outed if that serves some purpose for you. But, I don’t understand what is threatening to you about this presentation. Do I imply you are practicing irresponsible management? If you aren’t then it shouldn’t bother you. Do I imply the literature suggests this is responsible? The entire premise from the beginning is contrary to that. I am trying to make sense out of what I SEE IN PRACTICE IN REAL BUSINESSES EVERY DAY and then trying to move people past that.

    What is the bad outcome that you wish to prevent by twisting slides into a context they clearly aren’t intended?

    Dennis Stevens

  3. Glen B Alleman says on :

    It’s simple Dennis.
    You point out how BAD project management processes contribute to failure.

    But you fail to mention that when those project management processes are performed correctly – in the right domain – you’re “red herring” goes away. You don’t need to toss out the baby with the bath water.

    It is a recurring theme in the “agile thought leader” market place.

    I;d suggest it is irresponsible to suggest the replacement for BAD project management processes is a NEW project management process.

    I know you see it, but what you see (and I’m speculating) is the BAD application of GOOD process.

    This is the basis of the “hype” approach to problem solving. It works in dieting, tomato growing, child rearing, and agile processes.

    Do the right thing in managing development, in the right domain for those right things and you won’t need to start with the “waterfall” red herring approach.

    What I want to prevent and will be speaking about to the DoD in two weeks is to not buy into the idea that agile is going to save you DoD IT procurement until you get your current house in order.

    By this I mean until the core principles of project management are in place – the principles we use. including measures of physical percent complete using Earned Value as mandated by the FAR, you’re just going to waste time and money (our tax dollars BTW) chasing another magic bullet solution.

    Start with the basics of project management, get those straight, working, and applied. Then ask what agile can do.

    But that’s not the message being conveyed to that audience today. It’s that all those bad program management methods that are applied need to be tossed out and replace with the “new” method.

    That approach to reform (DoD acquisition or enterprise IT) has yet to work. Agile is NOT to the solution. Agile is a tool for developing software only when the other aspects of software intensive systems management are in place.

    I know you see people making mistakes all the time. But it’s not the process that is the mistake. It is the people misusing the process.

    Think of the inverse. I’ve was on a triage team for the very project Highsmith speaks about in his PMI charts. It is a bio-instrument firm who dove head first into XP for their next product release. Crashed and burned, blew 10’s of millions, never got the product out the door, fired half the techies. Was it XP’s fault? No it was the inability of the staff and the “thought leaders” to comprehend the complexities of the business and the new product development cycle. Software was but a small part of the product’s success. The agile guys (and they were big name folks) completely failed to understand the immutable principles of project management.

  4. Glen B Alleman says on :

    One more comment. I hear you saying repeatedly “I see it every day.”

    When I said similar things to Ron Jeffries at an ADC conference way back in the last century. His comment was “get better customers”

Leave a Reply