Tag Archives: agile project management

The Best Agile Certification Training

slippery-waterfallA quick confession I ?grew up? in a waterfall world. All of my early projects used a waterfall methodology. Another way to describe this could be a step or stair step approach.

We stepped through the phases. When we completed the initiation phase, we moved on to planning, then to design, then to construction. In theory you did not continue on to the next phase until the previous phase was 100% completed. Note the caveat of ?in theory?. Of course we had times where we overlapped our phases. If the design document was in final review, I would absolutely encourage team members to begin the early construction phase tasks. Some considered this to be risky. It seemed worthwhile to me, usually team members could complete the early construction phase tasks while the design document was officially approved (because it took a couple of weeks to get people to pay attention to and sign off on a document). The need for rework due to this ?early start? of the next phase was rare.

One day a renegade team started using a new approach. They used iterations. Instead of running an entire project through all of the phases step-by-step, they planned iterations. Each iteration created some piece of the project and did so by running through each of the phases. When an iteration was completed, another iteration was executed. This next iteration continued on or built on the piece of the project that was created by the preceding iteration. In this manner iteration-by-iteration the project was completed.

Well this almost led to civil war within the group. The tension was heightened when the ?iteration camp? told the ?waterfall camp? that project management was not needed for their work and that in fact you could not use project management techniques on a project that was based on iterations. Of course there was some management involved and of course the iteration based projects were still expected to provide a completed product within a specific schedule and budget. The rejection of project management was about the revolution (evolution?) of a new way of doing things and about the rejection of process heavy management.

The debate raged on, not just where I worked, but other places too. As things calmed down and it became clear that iterative or Agile was not a fad, the two camps began to make their peace with one another. The positive benefits that came from Agile were recognized and in turn the need for some type of project management was acknowledged. Agile and project management began to coexist and perhaps even to thrive!

Agile is fully accepted by the PMI? or Project Management Institute. You can become an agile certified practitioner or PMI-ACP? through the PMI?. What this certification does is show your knowledge of agile principles, practices and tools and techniques across agile methodologies. In fact you do NOT have to be a project manager to qualify for this certification. For more on this you should visit www.pmi.org.

agile-prepcast-logo-297x55If this sounds interesting to you and you decide to pursue your PMI-ACP?, then consider using the Agile PrepCast to help you study for the exam.(You can click on the words Agile PrepCast or follow this link to check it out – http://nanacast.com/vp/108394/237792/. I can safely recommend this PrepCast to you because it was created by the same team who created the PMP PrepCast, I trust them and I know that they provide a high quality product and experience. Should you purse the certification? Please do not pursue it just to add letters after your name or to your resume or CV. Do it because it makes sense to you and because you use Agile and have experience and expertise working with Agile.

By the way if you already are a PMP? and you decide to take a course to prepare for the PMI-ACP?, you can earn PDUs (professional development units) when you use the Agile PrepCast. What do you think of that, two birds one stone as the saying goes. (No offense meant to the birds and no actual birds were actually harmed during the creation of this blog post.)

Not sure if this is the right way to prepare for your PMI-ACP? Another reason why I trust the PrepCast products is because you can try it out for free.

Follow this link http://nanacast.com/vp/112605/237792/ or click here: Prepare for the PMI-ACP and you can request free sample lessons and then decide if this is the right approach for you. No muss, no fuss!

Good luck with your PMI-ACP!

PS. I am an affiliate for the Agile PrepCast because I trust them. If you do buy from them using the links provided here pmStudent will receive a commission.

Thank you

Agile Project Management: What’s Up?

There is a great new site in town about Agile project management.

They are running a series of interview/guest posts on The State of Agile.

To my surprise, Peter from AgileScout.com reached out to me and asked me to be one of the interviewees.? It’s pretty amazing to be included in this list of Agile thinkers and practitioners!

The Questions:

  1. Your (author) background?
  2. How Agile has changed (from authors perspective) in terms of methods, philosophies, ideologies, pragmatic applications, etc.?
  3. Where is Agile going (in the future)?

Being of the contrary nature that I am, instead of responding with a blog post format I recorded a video with a mindmap on my whiteboard instead.

Click the image below to go to AgileScout.com and view the video.? Check out the rest of The State of Agile while you are there.

Tuesday 10/26 ? Tobias Mayer

Wednesday 10/27 ? Derek Huether

Thursday 10/28 ? Ken Schwaber

Friday 10/29 ? Josh Nankivel (Video!) and Sara Broca

Monday 11/1 ? Lisa Crispin

Tuesday 11/2 ? Mark Levison

Wednesday 11/3 ? Marcin Niebudek

Thursday 11/4 ? ?Matthias Marschall

Friday 11/5 ? Vincent D?Amico

Implementing SCRUM…the basics – Part 1

I started to write a response to a recent blog post about the effect that a slowing economy will have on the adoption of?Agile project management methodologies when I realized?from the comments on that site that there may be some folks here that are not yet familiar with Agile/SCRUM. I’m going to speak specifically about SCRUM since it’s currently the most popular “flavor” of Agile. If you’re already familiar with SCRUM, then this is just another SCRUM 101…if you’re new to the idea, then I recommend that you read this before continuing…

If you’ve made it here, then you should understand what a departure these four tenets are, for most organizations, ?from the way they’ve always managed solving technical problems. As we begin discussing SCRUM, I’ll be painting the picture from the standpoint of a business that is using a single small team doing internal, LOB application development.?There are?minor variations of this content for those producing commercial products, ?and for instances where you might be a cog in a much larger machine, or performing non-appdev tasks like hardware, engineering, manfacturing, etc.. I hope to cover these scenarios in depth in future posts. That said, you need to understand that SCRUM lays out a few, simple roles:

  1. A “Product Owner” [someone from “the business”] owns ultimate responsibility for the behaviors and functionality of the system as well as the schedule of what features will be delivered and when.
  2. A “ScrumMaster” is responsible for removing any barriers – organizational, technical, inter-personal, etc. that are/might be preventing the team from delivering on it’s commitments.
  3. A “Team” consists of everyone involved in delivery…that may include architects, developers, designers, business analysts, DBA’s, QA pros, and perhaps marketing, training developers, technical writers, etc. Popular guidance suggests that a team should consist of 5-9, although it can be larger or smaller, as always, you should really have a valid reason for doing it.

and a few ground rules:

  1. All meetings are Time-Boxed.
  2. Development is organized into fixed duration, completely encapusulated, development windows [typically 30 days] called a Sprint.
  3. The Product Owner is responsible for collecting, capturing, prioritizing, and communicating the system requirements [called User Stories]
  4. Each Sprint consists of four major meeetings…
    1. Sprint Planning Meeting #1 is used by the team to review the Product Backlog and discuss the desired outcome of the Sprint.
    2. Sprint Planning Meeting #2 is used by the team, having?used the interim between the previous meeting to estimate the size of each item on the Product Backlog,?to choose how many of the top items in the list can be completely delivered in the next 30 days. This subset of the Product Backlog is called the Sprint Backlog.
    3. The “Daily Standup” is a daily, 15-minute meeting used by the team to report progress since the last meeting, report what each person will be working on before the next meeting, and finally to indicate what, if any, impediments there are to their progress.
    4. The Retrospective meeting happens at the end of the Sprint and is intended as an opportunity for? the Team, ScrumMaster, and Product Owner to candidly discuss what went right?and what went wrong during the Sprint, and then to discuss and assign specific actions in order to adapt the process for the next Sprint.
  5. The “Team” is self-organizing and is responsible, as a unit, for understanding and delivering the product envisioned by the Product Owner.
vertical_scrum

Vertical Scrum - Flickr attribution license: jurvetson

So, now you should have a general feel for who’s involved in the effort and what each person’s responsibilities are.

Now, the first thing you need to do to understand SCRUM is to set aside your feelings and understanding of organizational structures, reporting structures, and anything else that smells of command and control. SCRUM requires a new organizational philosophy?that typically manifests itself as a shift from the scenario where management controls?production to one where the workers are empowered?to innovate and the role of management is to alleviate?anything that slows or prevents production. Naturally, worker bees are usually OK with this because they are positively affected and empowered?by this shift, manager bees struggle with it because it takes their “power” away and expects them step into a role of “Servant-Leader”. If your ogranization [specifically management]?can’t? adapt to this shift and you still try to “make” SCRUM work, you’re either going to have severe managerial attrition,?failed projects across the board, or best case will be marginal successes with burned-out developers who feel caught in the middle/terrorized by the PM. You should also understand that SCRUM mandates very little, in fact, the SCRUM methodology is extremely lightweight and does not provide specific proscription for how you might implement it in your organization. The result of this has been mis-application of the principles and philosophies?behind?SCRUM, but more on that in a later blog post.

The second big mindshift you need to understand is the Agile approach to requirements. Contrary to the “waterfall” and “modified waterfall” approach to development, the collection of detailed requirements in SCRUM is deferred until the last moment. In?a “traditional” or “waterfall”?development process, the requirements are collected in detail at the beginning of the process, and then the development team goes off into?a closet and works to deliver according to the Statement of Work. ?In SCRUM, a User Story is a component of work and represents a reminder for the developer to have a detailed requirements collection conversation with the Product Owner regarding the specific piece of functionality. I’m sure that right now?you’re saying “this can’t work”, “my developers are too lazy to do that”, and/or “what about architecture”, and a thousand other questions. I’ll address these in future blog posts as well [this things is already approaching book status]. The benefit and net result of this approach to requirements is that the “customer” [Product Owner] can change the “scope” of the project [by manipulating the Product Backlog] in the midst of the project. In truth, and practice,?this type of “change” is actually encouraged as long as the change to the Product Backlog is not made to the Sprint Backlog [although this can also be accepted as long as the Product Owner chooses an item of?comparable size that can be moved from the Sprint Backlog?to the Product Backlog and that the item being removed is not already in progress]. Because SCRUM welcomes scope changes, the product that is ultimately delivered should be an exact match to the customer’s business requirement.

The first thing to do when implementing SCRUM is to evaluate your organization’s willingness, capacity, and commitment to making the change. Second, make the same assessment about your willingness to be an organizational change agent because whoever adopts SCRUM will have to be prepared to make a firm and consistent stand that you CAN, with some effort, produce a ballpark estimate of time and cost to deliver a project and you CANNOT produce a detailed cost and schedule estimate, Gantt Chart, Project Plan, and the plethora of other documentation that a traditional waterfall approach mandates. This is a particularly difficult concept to endorse when you’re accustomed to managers, customers, executives, etc. that demand to know the “Not To Exceed” costs and schedule up front. This “cannot” stems from the fact that, with a new team at least, you cannot estimate velocity [again, that’ll be in the next post]?and as such you cannot determine how many Sprints it will take to work through the complete Product Backlog.

SCRUM and Agile are not silver bullets, and adoption of them requires a serious and significant commitment from the organization to embrace change. It’s not for everyone, but for those that can embrace change, do believe that it’s better to deliver smaller functional bites of an application than to deliver a monolithic application, and are willing to turn their organizational structure on it’s ear….then you’re on the right path…please stay tuned for more.

Fast Money? No, Agile EVM!

Agile Earned Value Project Management

Agile Earned Value Project Management

…dogs and cats living together… MASS HYSTERIA! – Dr. Peter Venkman

No, it’s true!? Earned Value Management techniques can work with non-traditional project management methodologies, including Agile, Critical Chain, and Lean PM.

Today at a Sioux Empire PMI Chapter meeting here in Sioux Falls, SD I mentioned to the group that I had written a post on using EVM with Agile, linkinng to a great white paper on the topic.? Well, I tried to find it, and I couldn’t.? Now where did I put that blog post…I know it’s around here somewhere!

At any rate, here’s a new post with the link I promised (just for you Kurt!).? This is the best paper I’ve seen on using Earned Value Management in conjunction with Agile Project Management.? If you are looking for a killer Agile Project Management blog, check out Mike’s Leading Answers blog.? It’s also in the links on the pmStudent.com home page.

This paper is very short and sweet, right to the point.? It does a great job of relaying the concepts with a good dash of visuals thrown in.? After you’ve finished reviewing it, post a comment here and let’s discuss!

Agile and Earned Value Reporting, Anthony Cabri, and Mike Griffiths of Quadrus Development Inc.

Update:? Be sure to check out Glen’s comment, where he links us to another great whitepaper, Making Agile Development Work in a Government Contracting Environment.? Thanks a ton Glen!