Taking the Plunge

If I said I was unsure of what to write it would be purely for effect, and would reflect the wrong kind of uncertainty for the purposes of my post. 

A lot has been written about uncertainty, its multiple causes and effects.  It's no secret that people have different levels of tolerance for different types of uncertainty.  Being made up of multiple people, organizations, too, can have a wide range of responses to uncertainty, anxiety being a common response that can have a negative impact on the outcome of a change.  If you've ever been involved in a major organizational change, you are likely painfully aware of the impact that individual and organizational anxiety can have on the success of the change.

Rather than discussing how uncertainty and anxiety affect projects, in general, consider the impact that uncertainty and anxiety can have on rolling out an Agile methodology or framework in an organization.  Maybe you've worked for an organization that had a painful time rolling out Agile, or failed to roll it out.  Was it because Agile doesn't work?  There is plenty of proof to the contrary.  Uncertainty and anxiety aren't the only reasons that some organizations do not successfully transition to Agile; every organization deals with these factors when undergoing organizational change, and they don't all fail.

As mentioned in a previous post, Waterfall gives the illusion of certainty, early in a project.  Maybe this is why many companies use a phased approach to rolling out Agile.  Did you catch that?  Waterfall is used for rolling out Agile in organizations.  Agile is, by its nature, a source of uncertainty.  Especially the very first time an organization uses it.  Transitioning to Agile is a significant organizational change.  As such it can be a significant source of uncertainty and anxiety.  It's this uncertainty and anxiety that can result in the transition to Agile being painful or failing, although it is not a guarantee.  What can you do?  A couple of other people here on ProjectManagement.com have shared some thoughts on the matter:

Ken Whitaker

http://www.projectmanagement.com/articles/268340/I-Can-t-Seem-to-Get-My-Team-to-Become-Agile

Johanna Rothman

http://www.projectmanagement.com/articles/283783/Leading-Your-Organizations-Transition-to-Agile

If your company is transitioning to Agile, remember that you're not the first, and plenty of companies have succeeded.  If your company is committed to the change, even the painful parts, and assuming it is the right thing to do for your organization, you can succeed.

I have a request - not a challenge - I'd like to learn more about any companies that use an Agile approach to roll out Agile in other organizations, instead of a phased approach.  If you have any information on this, please post a reply.

Need 30-60 free PDUs?  Here's an oldie, but a goodie - PM Podcast:

http://www.project-management-podcast.com/index.php/pdu

Hybrid Agile?  There ain’t no such animal.  Really.  Agile is not a thing you do.  It’s not a framework or methodology.  Technically, it’s a vision statement and twelve guiding principles that can be applied to multiple project approaches.  Scrumban? Sure.  WaterScrumfall?  It’s out there.  Agile Waterfall?  Let’s talk about that for a bit.

Let’s start with the Agile Manifesto.  Can you value the items on the left more than the items on the right and still be doing Waterfall?  I’ll give you a hint; the answer starts with ‘YES’.  It gets a little more complicated, however, when you take a closer look at the principles behind the manifesto.

If you look at the first tenet, you have to look at the whole thing.  I don’t think that any project approach can claim, ‘Our highest priority is to satisfy the customer…’ without caveats.  In the case of Agile, the caveat is early and continuous delivery of a product that adds value.  Waterfall does not do this very well.

The next tenet brings to mind some of the things I want to discuss regarding uncertainty.  Who really welcomes changing requirements?  Almost everyone wants at least a little certainty in their life.  Waterfall gives the illusion of certainty early in the project, but change later in the project can kill a project.  Agile approaches can cause uncertainty in the business at any point of the project, which can sabotage the adoption of Agile in an organization with little Agile experience.  Work past your organization’s fear of uncertainty, and you will be better able to deal with change, regardless of whether or not you are using Agile.

I would love the next three tenets on any project, regardless of approach.  Engaged business users, trusted and motivated team members, working face-to-face in a supportive environment.  PM Heaven!  I think that the biggest factor that prevents this in Waterfall is that the team is usually expected to multitask on multiple projects, but it can be overcome.

Unless you are delivering in chunks, or phases, working product is not a primary measure of progress in Waterfall.  Like Agile approaches, however, working product is a measure of completion or success in Waterfall.

When the next tenet refers to sustainable development and being able to maintain a constant pace indefinitely, its talking about velocity, or cadence.  You can achieve a rough cadence in Waterfall, but if you’re not estimating using story points, t-shirt sizes, powers of 2, or something else that allows for relative estimating, you can’t really talk about velocity.  I think the term 'indefinitely' scares some people.  The business always wants an end date from IT, Agile or Waterfall.

The final four are hit and miss.  Continuous attention to technical excellence and good design can enhance success, even if you’re not striving to be Agile.  Documenting what is out of scope is not the same as maximizing the amount of work not done.  I wouldn’t want a self-organizing team to touch my SAP architecture.  Lessons learned held at phase gates (instead of waiting until the end of the project) can give a team opportunity to tune and adjust.

If the Agile Manifesto and its Principles are the determining factors in whether or not a project approach is Agile, I’d be comfortable debating the potential for Agile Waterfall without using a hybrid approach.  It’s not a perfect fit, but when you compare Agile approaches (Scrum, XP, DSDM, Crystal, etc…) to these factors, not all of them are a perfect fit, either.

Back to my clickbait-worthy title.  It’s not that I think that there’s no such thing as Hybrid Agile.  I think that there’s more than one thing that could be called Hybrid Agile, but they don’t all involve Waterfall, and there is the potential to be agile (not Agile) in Waterfall, without hybridizing the approach.  Does Agile really 'own' those principles?

I was going to lead off my post with more almost-free webinars, but I didn’t want to dilute the impact of my title.  I hope my ramblings sparked some thoughts for you, whether or not you agree.  If you are a member of ScrumAlliance, you should already know about this; if you’re not, and don’t plan to get a Scrum certification, you might not care.  To get to the point, ScrumAlliance offers free webinars to its members.  This is important because you need SEUs (Scrum Education Units) to become a CSP (Certified Scrum Professional).  Being a CSP means that you have an active CSM, CSPO, or CSD and have reported 70 SEUs and 36 months of Agile/Scrum experience in the last 5 years. (sidenote – I’m excited to finally be working for a company where I have the chance to get the experience I need to become a CSP.  It’s been a few years since I became a CSM and I’ll become a CSPO in the fall.)

Unless my priorities change in the next week, we'll talk more about uncertainty, next time.

After my last post, I had a "doh" moment regarding free PDUs.  I could be mistaken, but I'm pretty sure that PMI members have access to free 1 PDU webinars here on ProjectManagement.com.  Okay, so it's not exactly free if you have to pay to be a member of PMI, but if you're already a member, why not take advantage of the resources available to you?

I had an "aha" moment, earlier this week, while contemplating why some companies succeed at certain project management methodologies, while others don't. The answer started to form while reading Kevin Coleman's article, "The Best of Both Worlds."  In his article, he discusses two different teams who had to work together, one using waterfall and the other agile, and how both were very resistant to the other.  He concluded that the main reason for resistance was due to both being unfamiliar with the other's approach to projects, and seeing little value in it.

I had to think about this for a little bit, and I realized that Kevin was right.  One of the main reasons that companies succeed with agile, after struggling with waterfall, is training.  When a company adopts agile, both IT and the business (should) receive training on how the process works and how to do what is expected of them.  When was the last time one of your business sponsors or stakeholders was trained on their role and how to interact with the project team on a waterfall project?  (I see a conversation with my PMO Director in the near future…)  It rarely happens.  We (including me) often make the assumption that people know how to be part of a project, even though we know it involves more than just identifying tasks and getting work done.

Sure, you might create and distribute communication plans, document roles and responsibilities, conduct stakeholder analysis, and publish RACI charts, but experience demonstrates that these artifacts do not adequately train your business partners on how to effectively participate in a project.  It's more likely that they have their own expectations regarding how the project should be run, and you are not meeting them.

I gained additional insight into the success of agile at some companies during the PMI luncheon on Thursday.  Julie Jacob, Director of Agile Implementation with AgileDad, spoke on her experiences transitioning the mortgage company, where she worked, to agile practices.

As I listened to her speak about inefficient processes, knowledge hoarding, and people focusing on increasing their personal value at the expense of others, it was obvious that change was needed.  The approach they chose was agile, and it worked, but it wasn't the only approach they could have chosen.  They could have addressed their problems individually, but without an overall vision, they would have only solved individual problems and not seen as great an impact.  Agile provided the wrapper that they needed to give context to the solutions they needed to implement.

Just to add a little reality to the conversation, I need to point out that transitioning to agile won't solve all of your problems.  The thing to keep in mind, in Julie's case, is that they made successful organizational change.  Transitioning to  agile is just one form of organizational change.  When you tackle organizational change, problems with your processes and (possibly) people will make themselves known.  If you don't deal with them effectively, they may sabotage the change(s) you are trying to make.  Agile or otherwise, effectively managing change is one of the key elements needed for any endeavor to be successful.

One last thought.  I've started reading "The Agility Shift" by Pamela Myer.  I may write more about it in a future post.  One topic that it has sparked that I will likely post about next week is the role of uncertainty in project management.

I hope you're ready for my soapbox speech.

Being agile is about more than just using the latest framework or methodology.  I like to think of it in terms of being responsive.  A business needs to be responsive to the changing needs of its customers, or in the case of the MLM where I work, the distributor sales force that consumes our services and products, in addition to selling them.

There can be several layers of people and process between customers/distributors and developers, and each layer has the potential to help the business be more responsive, or to be a bottleneck, including but not limited to IT.  Each layer should have the right people who are empowered to make decisions about how they contribute to the responsiveness of the company.  Each layer should understand the processes of the other layers and how they help the business be more responsive.  There should not be so many layers that it becomes impossible to be responsive.  Business 101, right?  But some companies still don't get it.

If IT decides to do Scrum, for example, and the business is not engaged and educated on how to participate and what to expect, neither the business nor IT  are going to have a pleasant experience. And yet, this happens, and people blame Scrum for not working.  

Have you noticed that there are no project managers mentioned in agile methodologies and frameworks?  Have you wondered if it was intentional?  Agile was developed by developers... Don't let this scare you or make you paranoid.  Before agile takes overs the world, we're going to see a transformation in how project management is approached.  It's already started, but we'll need to wait for the polarization between views about agile and waterfall to subside to recognize it.

What is this transformation?  It is the realization that the project manager and the organization need to know how to identify and use the right tool for the job.  Some projects will be more effective using an iterative approach, others will benefit from a more linear approach.  The successful and agile companies will be those that are set up to take advantage of the approaches that enable them to be flexible in how they respond to demand.

You, the project manager, need to be prepared to lead any type of project, and be a coach or mentor to those you work with.  Put another way, your job isn't to be just an expert in agile or waterfall; your job is to execute, using whatever approach is required to complete the project.  This is how you will become a truly agile project manager.

Okay, let's catch our breath for a moment.  That's enough agile for now, but I have a follow-up item before I go.  I haven't been able to find any information on the PDUs2GO website about their free 1 PDU webinars.  It looks like you'll have to go to their website and get on their mailing list to get notifications about the webinars.  I'll find a different provider of free PDUs to mention in my next post.

I know, it’s been too long.  After serving two terms as VP of Education for the PMI Northern Utah Chapter, I decided to spend more time with my family and pursuing hobbies.  If you hadn’t noticed, Project Management can be a highly intellectual effort, with long periods between demonstrable results (depending upon your projects and the methodology/framework you use).  I needed some sort of cathartic release with fast turn-around time, so I’ve gotten into blacksmithing.  I’m in the middle of a project, setting up a small blacksmith shop in my garage, but that is a post for another time.

Historically, my blog was about getting and maintaining the PMP credential.  I’ll still touch on that, occasionally.  For example, I recently received an email from PDUs2Go that they are going to start offering free 1 PDU webinars, again.  I haven’t found information on their site, yet.  Once it’s available, I’ll post it here.  I think, however, it’s time to branch out.

As the only CSM (Certified Scrum Master) in the PMO, where I work, I was recently asked to teach a class on Scrum to another team.  The company where I work is starting to make headway into adopting Scrum, and some of the teams that normally would not consider Agile are starting to take interest.

It was a half-day class where I presented the hype, the reality, and a little bit of sarcasm about Agile and Scrum (because Scrum is not the only way to be Agile).  The point that resonated the strongest with the class, and me, is that being agile is about more than just adopting agile development practices.  It’s about so much more than just IT trying a new approach.  I think that’s the topic for my next post.

Before I close, I want to post a little about the PMINUC professional development conference I attended in April.  Kudos to the current board for a job well done.  It’s incredible how much they’ve grown in the past few years, and how much more they are doing for their members, now.  If I didn’t have other commitments, I’d be more than excited to be part of it again.  My favorite speaker was Spencer Horn.  He gave two presentations.  I would have gone to both, but decided to diversify the classes I attended in order to attempt to manage my “Talent Triangle.”  I attended the session on Branding Yourself, which was probably my biggest motivation to start my blog back up, again. If you ever have the chance to work with Spencer, or attend one of his presentations, I highly recommend it.

I was especially touched during the presentation from Operation Underground Railroad.  I don’t know if I know anyone who has been directly impacted by sex trafficking, but it was eye opening to find out how pernicious it is, and to realize that slavery is still alive and well, even in the US.  I’m going to look into ways that I can contribute to O.U.R.  Here’s a link, if you’re interested.

https://ourrescue.org/join-the-fight

My final thought from the PDC, and for this post, is that I am excited that I won a training class from the BrainTrust Consulting Group.  I’ll be taking the CSPO (Certified Scrum Product Owner) class in the fall – the next time it’s offered in SLC.  I feel like a dork admitting this, but I’m excited, and not just because I won something.  When I got my CSM certification, in 2007, the class placed a lot of focus on the role of the ScrumMaster and how to run a Scrum project.  I look forward to formal training on what the Product Owner should be doing, both before and during the project (especially before), as this will help me coach the business as Scrum becomes more prevalent where I work.