Recently I’ve been asked to write an occasional article for the Weekly PM Insights newsletter.  This newsletter is published every Sunday night and so far has had some excellent articles.  There are some very good names in the world of Project Management writing articles, and Ray Posch (the editor) was open-minded enough to ask me to write the occasional article dealing with an agile topic.  Good articles, open to agile – hardly sounds like a project manager newsletter!

Ray is doing a great job and if you are a project manager it is probably worth subscribing to get a few articles a week in your email.  It won’t disappoint!

By the way, my articles so far appear in issues 1, 5 and 7, so Ray is definitely keeping to his promise of publishing something on agile quite frequently!

Related posts:

1. 2010 will be exciting for Agile Bob on Making Agile a Reality The new year starts tonight.  I’m extremely excited because I have HUGE...
2. Agile hip surgery? I’m always looking for uses of agile in areas outside of software...
3. Merry Christmas! This blog entry is being posted on Wednesday, December 23 at noon...

Question:  Which is better: a) Working nights and weekends to meet iteration commitments, or b) Admitting the commitment was too much and working normal hours regardless of the commitment?

Many people would say answer (a) is better.  I might even say that if it were a one-time anomaly, but too often it doesn’t happen just once.  The team ends up setting an artificially high velocity and are then asked to keep a similar velocity in the future.  As a result there are more and more iterations with impossible deadlines and the agile team begins to feel they are on a death march.  I even had one person in a course tell me their management had them all sign a document saying they would work nights and weekends as necessary because the company really needed the product as soon as possible.  Seriously?!?!  On an agile team???  Ouch!

99 times out of 100 my answer to the original question would be (b).  Work at a sustainable pace (no sandbagging allowed), determine a realistic velocity, and go on from there.  During the iteration retrospective an obvious discussion question would be why such an unrealistic commitment was made in the first place.  Sometimes it is just an anomaly caused by uncertainty.  That can happen occasionally and is no cause for alarm.  However, more often than not it is caused by a team trying to meet an artificial deadline and convincing themselves they can do it.  Don’t fall into this trap.  Death march projects are no fun and they may even be less fun when done in an agile way.  Seeing failure or ridiculous overload every two weeks can get to be horribly depressing!

Remember, a sustainable pace is one at which the team can perform for very long periods of time – forever basically.  I like to add the team takes pride in how much gets accomplished each iteration.  This helps prevent sandbagging because you can’t take pride in the amount completed if you sandbagged it.  Also remember sustainable doesn’t mean no vacations!  It is necessary for downtime to recharge.  Sustainable could even mean occasional overtime if the team chooses to meet their commitment in order to help them feel proud of the iteration – however this should not happen very often – if ever!

Project managers and Scrum Masters need to watch the mental and physical health of the team.  Be the conscience of the team when it comes to maintaining a sustainable pace.  Re-read that last sentence and ask yourself when the last time a project manager asked a team to reduce their hours because it wasn’t healthy!  If the pace of the team is not sustainable several undesirable effects are likely to occur:

1. Defects will increase.  Tired teams let more defects through.
2. Work output will decrease.  Tired teams do less work in more time!
3. Morale will drastically decrease.  This may lead to employee turnover at a most unfortunate time in the project.
4. The blame game will become common.  (Not our fault you didn’t say X.  I said X.  Did not.  Did so…)
5. The team starts to abandon good practices for those that “seem” faster.  Sorry, but test-driven development (TDD) is actually faster than just writing the code and throwing it over the wall to QA!

Do you have any funny stories about sustainable pace or a lack thereof?  If so, please post a comment.  I’d love to have examples to use in the future!

Until next time I’ll be monitoring teams I coach for use of a sustainable pace because there is no other way of Making Agile a Reality^® for the long term!

Related posts:

1. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
2. Agile antipattern: Working overtime Ever feel like the guy over there to the left?  Yeah, me...
3. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...

Yesterday’s blog post dealt with how to manage scope for an agile project.  Today I have to admit it was a bit of a setup.  It was designed to set up today’s blog post which is really the important one!

See that pile of money over there to the left?  That represents a small fraction of the amount of money your organization is potentially wasting by not being able to properly manage the scope of projects.  I want to be clear this is not about project delays and overruns caused by scope creep.  I am actually writing about something completely different.  Something much more fundamental and actually fairly easy to obtain when an organization has truly embraced all that agile has to offer.  To me this is one of the most important benefits of agility, but the number of organizations doing it well is extremely small.  Warning, this is a LONG blog entry, but I think it is well worth the effort to read it!

The topic I’m writing about is the ability to manage scope and expectations properly.  The gains available by doing this are truly staggering.  If your organization was given the opportunity to increase ROI by 100% per project would someone in the organization be tasked with looking into the opportunity?  What if the ROI per project could be increased by 200%?  If the opportunity was for 500% increase in ROI per project would your organization perhaps have more than one person look into the opportunity, or would it sound too good to be true and therefore be discounted?  I know this sounds unbelievable, but the ability to achieve much, much higher ROI is very real, and it only depends on your organization’s ability to manage scope and expectations effectively.

Do I have your attention yet?  I hope so because this is really valuable information that most people just gloss over in various agile courses.  I have to admit that I didn’t cover it very well until recently.  I glossed over it mostly because I didn’t understand it very well.  Now I understand it and I’ll try to help you understand it.  The basic concept is VERY simple and can be covered with just 3 words:

More frequent releases

Yup, that’s the key.  It is much easier said than done though.  It means expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.

Let’s use a standard scenario as a starting point.  In this scenario a team of 8 people work on a project for a year with an anticipated ROI of 100% after 2 years.  In numbers this means the organization spends $1,000,000 (approximately) in 12 months to build the product and they expect to get $2,000,000 in revenue within the 12 months following release.  ROI is calculated as $profit/$invested which in this case is ($2,000,000-$1,000,000)/$1,000,000 or 100%.  Another interesting number is cash expended, which in this case exactly matches the investment since we did all of the investment prior to receiving any return.

Let’s assume that scope can be managed so the product can be delivered in two phases, each taking 6 months.  Let’s further assume each piece of the product is worth about half of the revenue value of the complete product.  In this case the team works 6 months at an investment of $500,000 to build the first piece of the product.  They then work 6 more months at an additional cost of $500,000 to complete the second half of the product.  However, after 6 months revenue starts to be brought in for the first release.  This revenue equals half of what was originally expected for a full product, so after going through some calculations we realize the amount of revenue during the first 6 months of release of the first half of the product would be $500,000 ($2,000,000 for full product for 12 months = $500,000 for half product for 6 months).  Interestingly, this exactly matches the cost for building the second half of the product, so the cash expended is actually only $500,000 for building the product vs. $1,000,000 for building the product in one step.

Now let’s look at the other numbers.  After phase 2 of the product is completed it too starts to bring in revenue.  We now have the complete product, so we can get full value of it during each time period.  In other words, during the next 12 months it will generate $2,000,000 in revenue.  This brings total revenue to $2,500,000 which means our ROI is now 300% (higher profit divided by smaller investment – $1,500,000 profit / $500,000 invested).  Remember, all we did was have two releases of approximately equal value.  Nothing else changed, but half the cash was saved and more revenue was generated.  Here is a table showing this scenario:

Time to take another step.  Let’s make the assumption we can release 4 times per year with approximately equal valued releases and the same assumptions as in the above scenarios.  Now we work 3 months at a cost of $250,000 to generate release 1.  We do the same thing every 3 months until the year is completed.  Each release generates 25% of the value of the entire release, which over a 3 month period would be $125,000.  This leads to the following table:

Now we have a situation where our cash outlay is reduced to $375,000 and our revenue has increased to $2,750,000.  This gives an ROI of 467%.

For the next scenario let’s say we can do the same 4 releases per year, but now we release higher value items first (after all, we are working from a prioritized product backlog, right???).  In this scenario let’s say release 1 is worth 40% of the total, release 2 is worth 30%, release 3 is worth 20% and release 4 is worth 10%.  Now our table is as follows:

$300,000 cash invested and $2,000,000 total profit which is now 667% ROI.

Bear with me, almost done.  For the next scenario let’s not have the team build the features worth 20% or 10% of the total product value.  They are low priority items anyway.  Doing this would generate the following table:

In this scenario we have the same cash investment of $300,000 but now we only made $1,800,000 in profit for an ROI of 600%.  Why would we want to do this?  Well, what is our team doing during those second 6 months of development?  In this scenario they are idle.  So let’s use them!  Find another project with similar parameters and have them start it 6 months earlier than whey would have otherwise.  Consider the exact same setup as in the previous scenario except we’ll be generating revenue from two different products after month 9.  In this case the table looks like:

$2,900,000 profit on an investment of $300,000 is an ROI of 967%.

Do I still have your attention?  If so, consider one final scenario:  The total cash invested in this project is only $300,000.  The organization was originally willing to commit $1,000,000 for the project.  Can you find 2 more teams and enough projects to do the same thing two more times?  If so, the original $1,000,000 investment will have been reduced to $900,000 and instead of $2,000,000 in revenue at the end of year 2 the organization could bring in $11,700,000 which is 5.85X more revenue than the original scenario and $7,700,000 more actual cash!  This equates to a 967% ROI for each of 6 products across 3 teams with 12 total releases per year.  Remember at the beginning when I said the cost of releasing would be negligible compared to the benefits?  I also mentioned 500+% increase in ROI was possible.  Do you believe me now? 

I know this was a VERY long blog entry, but I think you’ll also agree this is an important topic to understand.  To see another way of explaining it try Clarke Ching’s Rocks Into Gold presentation on Slideshare.  I hope after reading this you are as excited about the possibilities as I was when I had my “lightbulb moment” about it.  I think it is vitally important for organizations to truly understand these concepts.  I hope those of you reading this blog entry agree and will pass it on to others so they can have their “lightbulb moment” and hopefully be able to make it happen!

Oh, one last thought – if you can prioritize so the percent of value delivered by each release is even higher, then the numbers can go even higher!  For example, can a first release be worth 50% of the value?  Can a second release be worth 40%?  These may be possible in light of studies that say more than 50% of features are rarely or never used.  Said differently more than half the software in existence has no value.  If we eliminate that half, maybe we can make the earlier releases worth even more!

Until next time I’ll be Making Agile a Reality™ by helping organizations understand why managing scope in order to have more frequent releases can be so important to their bottom line!  By the way, my good friend Richard Lawrence is a person who really helped me understand this concept, so thanks Richard!

Related posts:

1. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
2. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
3. Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too...

As an agile coach I have attended a lot of daily stand-up meetings.  I can’t count the number of times I’ve been in a meeting that went something like this:

Scrum Master: OK everyone, it is time for our status report.  Let’s start with Joe.
Joe (delivered in a boring monotone voice): Yesterday I did A.  Today I will do B.  Nothing blocking me.
Scrum Master: OK, now Bill.
Bill (delivered in a boring monotone voice): Yesterday I did C.  Today I will do D.  Nothing blocking me.
Scrum Master: OK, now Jane.
Jane (delivered in a boring monotone voice): Yesterday I did E.  Today I will do F.  Nothing blocking me.
(continue in this pattern until all have given their answers)
Scrum Master: Thanks everyone.  Great status meeting.  See you all tomorrow at the same time!

Can 15 minutes possibly be any more boring and useless (please don’t answer that because I REALLY don’t want to know there is a worse fate than being in this type of daily stand-up meeting!).  So, what can you do to change things?

For starters, the daily stand-up meeting IS NOT A STATUS MEETING!!!  We don’t need a status meeting.  Status is what we get from our task board and burndown chart.  Why have a meeting to cover what we can just look at either on the wall or in whatever tool we use for our project?

When I tell teams it is not a status meeting I inevitably hear ”If it isn’t a status meeting, then what is it?  It sure seems like a status meeting with the 3 questions we are supposed to answer!”  I even have to grudgingly admit I can understand the confusion.  It is very easy, even for good agile teams, to fall back into the “status-like” method of doing daily stand-up meetings.  But it isn’t a status meeting and there are ways to improve:

1. If you aren’t already “doing it right”, start!  In other words, for starters, answer the 3 questions and move on.  Don’t allow too much interaction about the answers – that can and should happen outside of the daily stand-up.
2. Do it “right” and don’t allow outside observers to participate.  Remember the chicken and pig scenario.  Only “pigs” get to participate.  This is their time, if someone wants to say something to the team they can do it at another time.
3. Use a “talking stick” or some other token which has to be in someone’s possession for them to speak.  This stops people from talking over one another and also stops side discussions.
4. To make the meeting less “status-like” the project manager/scrum master should be a bystander!  They can start the meeting by calling on someone to go first, but then they should back off and stay in the background.  Each person who speaks picks the next person who will speak.  An important note here – it is not necessary for the Scrum Master to be at the daily stand-up!  The team should still go forward, even without the Scrum Master.
5. Don’t make the meeting about moving index cards, sticky notes, online tasks or anything else similar to these things.  You can update the task board outside the meeting.  The meeting is about exchanging information not the ceremony of updating status.
6. As each person answers the question “What did I do since we met last?” everyone should be thinking to themselves “Is there anything that person could help me with based on what they just completed?”
7. As each person answers the question “What will I do before we meet again?” everyone should be thinking to themselves “Is there anything I know which could help that person with their new item?”
8. Start the meeting on time and invoke some sort of penalty for late arrivals – the latest getting the worst penalty.  Keep it fun, but it it needs to be meaningful at the same time.  This is about respect of other people.  If we don’t respect the people we work with enough to show up on time for this meeting then we have a big problem that agile may not be able to solve!
9. Encourage collaboration by having another question after everyone has spoken – Who needs to talk to someone else for help or to give help?  Then do it!  This encourages people to be thinking thoughts like #6 and #7 above.
10. If the daily stand-up is being done over the phone be sure to have everyone say their name clearly and loudly enough for everyone to understand it.  I’ve seen people on new teams never know who was talking and then not be able to help someone because they didn’t know who to help!
11. DO NOT TRY TO SOLVE PROBLEMS!!!  This is a meeting to expose problems, not solve them.  Not everyone has to be involved in solving every problem, and in fact that will cause more disruption than benefit in most cases.
12. Stick to 15 minutes or less for the meeting.  If the team is too large to have it done in 15 minutes then analyze why the team is so large and whether it should be split in some fashion.  Remember, because of the number of communication channels involved, the ideal team size is 7 +/- 2.  I usually say that is ideal, but you can go larger if you are willing to put up with the pain.  If it is larger than 12 you really need to look at why.
13. If the meeting is in person, then actually stand during the meeting.  It is a proven fact meetings will take less time when everyone is standing rather than sitting.
14. If managers will be participating (I only have them participate as pigs if they are actually doing work!) then consider having them go last.  Sometimes a manager can set the wrong tone for a meeting just by the words they use and how they say them.  When they go last this issue is avoided.  It also helps keep the meeting shorter
15. In order to focus on completion and success, consider changing the questions to “What did I COMPLETE since we last met?” and “What will I COMPLETE before we meet again?”  This tends to help with focus as well as making people painfully aware tasks should be able to be completed in less than one day.

I’m going to stop at 15 items this time.  I have several more, but I’ll save them for a future post.

Thank you for reading this.  If you have suggestions, please leave a comment.  I’d love to expand the list!  Until next time I’m going to be Making Agile a Reality™ by helping teams convert boring daily stand-up meetings into vibrant information sharing and collaboration meetings!

Related posts:

1. New to agile? Don’t settle for mediocrity James Shore recently changed the entire focus of his company. This blog...
2. Agile antipattern: Doing Agile! I spent the past week in Orlando, Florida  at the Agile Development...
3. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...

I’ve been working the past several weeks with some highly distributed teams.  Each team requires a way to track their project effectively (when you have people in 6 different states and a few countries cards on the wall no longer work!), collaborate, use planning poker and store things pertinent to the project.  What can you do when co-location is just not a possibility?

It turns out there are many ways to help overcome pieces of the problem.  Unfortunately, the problem also has many pieces!  Below I have broken out some of the tools I have seen used successfully to overcome various issues distributed teams face:

Issue: Lack of high-bandwidth communication

This is probably the biggest problem distributed teams need to solve.  How close can you come to high bandwidth communication?  That should be the question you ask all the time.  Since this is about tools, some that I’ve seen used are video conferencing that is live all the time (cheaper than you think when done over the Internet), extensive use of Skype, instant messaging of various flavors, and a good old fashioned phone call.  For teams that overlap the work day at all, some form of instant messaging is used nearly universally.  I’ve also seen teams use Twitter in “private” mode to share information with each other.  For any of these methods it is vital to have an easy method of storing the critical information which is exchanged. 

Issue: Cannot use “cards on the wall” to track iteration progress

This is the issue that is probably easiest to deal with because it is where most vendors of agile tools have focused.  You basically have 4 choices here:  1) create something of your own to solve this problem, 2) use something like www.cardmeeting.com to still try to simulate cards on the wall, 3) use an Excel spreadsheet for tracking, or 4) use a web-based tool designed for the job.  To me numbers 1 and 3 are not viable solutions.  There are too many problems associated with both of them.  Number 2 is interesting, but only for a short time.  It doesn’t quite have enough flexibility to make it easy to use for this particular type of situation.  That leaves number 4 as the only true option (again, this is my opinion, yours may be different).  In this category are LOTS of tools.  VersionOne, Rally, Pivotal Tracker, TargetProcess, Microsoft TFS and many other applications can do the job.  I have not mentioned any open source tools because I’ve seen too many teams try them, get stuck and have no good place to turn for help. 

The two having the largest market share by far are VersionOne and Rally.  Both have a free version for evaluation and in both cases they also have a free version which can be used by small teams forever.  I know there are lots of other tools out there, but I’ve not personally used them, so I can’t put them in here.

Issue: Cannot play Planning Poker remotely

OK, I lied earlier – THIS is the easiest problem to solve!  Assuming you can get everyone on the web at the same time, www.planningpoker.com will suffice quite nicely.  This site has several different variations of point scales to use, can import stories, has a timer you can use and basically makes playing Planning Poker remotely as simple as possible.  Kudos to Mike Cohn for setting it up and keeping it free for the agile community to use (Mike has also written a couple of books we have listed on our resources page).

Issue: Information storage and sharing is difficult

This is another area with lots of potential answers.  Wikis are very popular and probably the number one choice for taking a stab at this particular issue.  Sharepoint is another option that I’ve seen work well.  Many teams using an agile project management tool like VersionOne (or one of the others mentioned) will create links from the tool to wherever the additional information is stored, thereby allowing them to use any storage medium including something like subversion.

While there are lots of choices in this area, good agile principles tell us to eliminate waste.  This is a huge potential area for waste.  If you can’t find something then it might as well not have been there at all.  It is vitally important for teams to pick a tool and a way of using that tool which allows for easily finding information when necessary!

Other random tools:

www.etherpad.com – real-time collaborative text editing

Google Docs – online document sharing

www.tinychat.com – instantly create and use a chatroom

www.scriblink.com – online whiteboard

www.webex.com and www.gotomeeting.com – online meetings with presentations or sharing a desktop for others to view

As you can see, there are a LOT of tools available for use with distributed teams.  Let the agile process work for you by having the team use one for an iteration and at the iteration retrospective (you do have those, right?) decide whether to continue using it, change how you use it, or decide to try a different tool.  There are far more tools than I’ve listed.  Let Google be your friend and find ones that solve your specific problems.

Until next time my clients will be using many of these tools as they continue Making Agile a Reality™.

Related posts:

1. Are Agile Lifecycle Management tools worth it? There are many well known agile pundits, practitioners and trainers that very...
2. New to agile? Tips for better daily stand-ups As an agile coach I have attended a lot of daily stand-up...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

Now that I have your attention, let me be VERY clear I don’t believe the title of this post.  However, many people do believe it, and that is troubling. 

Now that some of you are confused let’s back up a minute and explain the term PMP.  It stands for Project Management Professional.  It is a specific level of achievement obtained through the Project Management Institute (PMI).  The PMP level recognizes demonstrated knowledge and skill in leading and directing project teams and in delivering project results within the constraints of schedule, budget and resources based on the Project Management Body of Knowledge (PMBOK).  The PMP designation requires a significant amount of documented project management experience as well as demonstrating significant knowledge of the PMBOK through passing a rigorous test.  All of this is very good in theory, but there are some issues which may need to be addressed.

As I said in the first sentence, I don’t believe the title of this post as it is written.  Unfortunately, I can also see reasons why many people do have this particular belief.  The biggest reason being the way most PMPs look at the world of project management.  To them it is the traditional interpretation of the PMBOK or it isn’t worth doing.  I find this interesting because PMI has an official position which is the PMBOK is process independent.  It is simply good project management practices regardless of the underly process being used.  Yet traditional interpretations tend to conflict with agile interpretations of the same document.  I touched on some of this in an earlier blog post containing my feelings about agile and various bodies of knowledge.  At that time I was focusing on my observation that simply implementing a process based on a body of knowledge document was very likely to lead to a traditional waterfall process.  Now I want to take that thought a step further and say a traditional intepretation of the PMBOK while using an agile process is going to lead to conflict and eventually a project failure.  I know that’s a bold statement, but if you take a big picture view, a non-agile PM trying to help an agile team is definitely a square peg in a round hole.  Eventually something will break if the peg is going to get inserted at all.  Others agree with me.  Mike Cottmeyer has a presentation he does called Agile PMP: Teaching an Old Dog New Tricks.  Alex Hamer also has a blog post on this topic.

Fortunately, the PMBOK can be interpreted through something I’ll call “agile sunglasses.”  When you wear your agile sunglasses and look at the PMBOK you can see how the various practices may actually be useful in an agile world.  You may do them much differently than you would on a traditional project, but you can still do them.

I used to think it would be great if there was a translation between the PMBOK and agile.  I guess Michele Sliger and Stacia Broderick thought the same thing because their book, “The Software Project Managers Bridge to Agility” is exactly that!  It translates from PMBOK terms to agile terms and gives PMPs some direction on how to change from traditional PMs which are ineffective in an agile process to agile PMs with a lot of useful knowledge they can draw on to help their teams succeed.  This book is a must read for anyone stuck on traditional PM practices.  Anonymously drop a copy on your PMPs desk if you need to!  Click on the image of the book if you need to order it.  Go ahead, do it now, the rest of this post can wait.

In my experience the best agile project managers were also the best traditional waterfall project managers.  I believe the primary reason for this is they have found success by using some agile techniques without even knowing it.  This shows up when they are in a course and say things like “I already do that.”  When I press further I find out they have been very successful, and they are truly doing some agile things within their waterfall process.  At that point I can smile and know the team will be even more successful with the lighter weight agile process.

Now, back to the title of this post.  If it said “On an agile team never have a PMP who relies on a traditional interpretation of the PMBOK” I have to say I’d agree.  Unfortunately, the reality is many people fitting that description are in companies currently undergoing agile transformations, so what do you do?  I would start with some sort of coaching or mentoring.  Most people who have achieved the level of PMP are very knowledgeable and can adapt if given a chance and a path to follow.  In an organization undergoing agile transformation I like to schedule regular meeting time with all people fitting this profile.  This allows me to be sure they all share their experiences so they learn from each other and improve rapidly. At some point there is a moment when they spread their wings and fly again on their own.  Give them some time to allow it to occur.  However, don’t give them too much time.  There are some people in every role that won’t be able to transition to an agile process.  Project managers are no different in that regard from ornery developers that won’t change.

Until next time, get to work with your PMPs to help them adjust their habits and practices so that together you are working on Making Agile a Reality™ for your organization.  Let me know how it goes or if you have had experiences others can learn from.

Related posts:

1. Agile and various bodies of knowledge (PMBOK and BABOK) In case you aren’t aware, there are at least two international organizations...
2. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...
3. Agile for Business Analysts This past week I was fortunate enough to be a speaker at the...

This is the topic of my next Mile Hi PMI Chapter Workshop to be presented on April 11, 2009.  I do workshops on agile topics for the local PMI chapter a couple of times per year.  They are great opportunities for me to stay in touch with the project management population.  I also believe the more PMI members exposed to agile, the more likely agile will be able to attain status as the product development methodology of choice.  After all, I am working at Making Agile a Reality™!

There will be two sessions of this presentation.  The morning session runs from 8:30 until noon.  The afternoon session runs from 12:30 to 4:00.  For PMI members it is $20 to attend and you receive 3 or maybe 3.5 PDU’s (I don’t remember which!).  For non-PMI members it costs $45 to attend, but it’s a great presentation and well worth the price of admission! 

For more information or to sign up click THE MORNING SESSION or THE AFTERNOON SESSION.

I hope to see some of you there.  I know the economy is tough right now.  If you would like to attend, but money is an issue, please contact me so I can see if there is anything I can do to help.  If you are in, or hope to be in, a position of agile leadership, this presentation is a must see!

Related posts:

1. Agile for Business Analysts This past week I was fortunate enough to be a speaker at the...
2. Free Event! Agile Adoption: The Real Story On October 20, the Agile Cooperative will be hosting a free one-day...
3. New to agile? Don’t make it too hard! OK, so this isn’t my normal type of blog entry.  I don’t...

In case you aren’t aware, there are at least two international organizations which have created impressive bodies of knowledge.  The International Institute of Business Analysis (IIBA – www.iiba.org) and the Project Management Institute (PMI – www.pmi.org) have created the Business Analysis Body of Knowledge (BABOK) and Project Management Body of Knowledge (PMBOK) respectively.  Both of these works are impressive in their scope and level of detail, but I believe they both have a fundamental flaw.It is my belief that someone blindly following either the BABOK or PMBOK will end up with a process and result consistent with the waterfall model.  This is interesting to me because both organizations claim their works are process agnostic and simply represent best industry practices regardless of the underlying process.  I actually agree with them – SURPRISE!  But, with a caveat – you have to look at the practices with what I’ll call “agile glasses” in order to end up being consistent with an agile process.   You simply cannot blindly follow what is written because it is too easy to fall into the waterfall mindset when you do things in that manner.  Instead, look at each generally accepted practice through agile glasses and decide if the practice has a useful place in your process, and if it does, how you would use the practice effectively.

Both the BABOK and PMBOK are consistent with an agile approach to software development, but not without interpretation.  Remember, both works are simply guides that clearly define generally accepted practices.  They are not meant to define process, so don’t interpret either one from a process perspective.  Instead examine the practices to determine which fit and how they fit and you will end up with an agile framework which is still consistent with either or both documents.

I guess the Bob-ism here is “Attempting to use the practices in a body of knowledge document is likely to lead to a waterfall implementation if an agile interpretation is not kept in mind.”

If you want a heavyweight process then feel free to follow the documents as written.  If you want to maintain a lightweight agile process then interpret the documents from that perspective and utilize generally accepted industry practices to actually improve your agile process!  You may be surprised how you can improve through the use of generally accepted practices used in an agile appropriate manner.

Related posts:

1. Never have a PMP on an agile team Now that I have your attention, let me be VERY clear I don’t...
2. Agile for Business Analysts This past week I was fortunate enough to be a speaker at the...
3. Agile antipattern: Using manual tests In an agile environment manual testing is fine – except for when it...