Taking the Plunge

NOTE:  Going forward, when using the word Agile to represent the several methodologies and frameworks associated with Agile, I will use the phrase "flavors of Agile," unless I am quoting someone.  If I am talking about a specific framework or methodology, I will identify it by name, i.e. Scrum, Kanban, and so on.

I was recently asked, "Which projects should you use Agile on?"  I'm not sure if my answer was satisfactory, so I thought I would address the question in more detail, here.

For starters, you should always use the Agile principles that apply to your project, even if you're not using a specific flavor of Agile.  (See my previous post for further explanation.)  There are several variables that need to be considered when evaluating when to use a flavor of Agile.

1. Is your organization already using a flavor of Agile?

If your organization is already using a flavor of Agile, the question of when might be out of your control.  If you're not using it for every project, you should have specific guidelines for determining when to/not to use it.  One of the basic guidelines should be whether the project would benefit from or be hindered by iterative development.  Don't assume that just because you have been successful with one flavor of Agile that you will be successful with another.  You're headed toward organizational change, and it doesn't always work that way.

2. Do leadership and non-IT components of your organization understand and support Agile processes?

If your organization is not currently using a flavor of Agile, this is a must.  You must have top-down and lateral support.  If 'Going Agile' is just an IT initiative, you will fail.  If the experience is too painful, people may never want to hear the word Agile again, even if the failure was caused by others not understanding the benefit of the specific flavor of Agile or how it works.

You also need to make sure that everyone using your flavor of Agile is trained on how to participate in it and what to expect from others.

3. What is your company culture?

Does your company embrace change and face organizational issues head on?  Switching to a flavor of Agile is an organizational change, and you will have to face organizational issues in order to change successfully.  The first time one of your teams uses a flavor of Agile, it will be bumpy.  If you're not prepared for bumps, and if the organization cannot handle bumps, it would be an understatement to say that adoption will be difficult.  When working on a large CRM implementation, overseas, I found myself regularly telling the team, "Remember, it's not about whether or not we encounter issues, it's how we deal with the issues that matters.  There will be issues; it's up to us to make this successful."  Are you ready to be a cheerleader?

4. How much is known about your project?

Do you have a strong understanding of the complexity of the project and how complicated the work is, when looking at requirements, technology, and process?  If it is a well-defined and/or simple project, you may not realize any greater benefit from a flavor of Agile than you would from Waterfall.  As details become more vague and the project begins to take on more of an exploratory feel, a flavor of Agile becomes a stronger candidate for success.  As you foray too deeply into the unknown, you may find your time better spent adding a little more definition to your project before choosing a methodology for how you will execute it.

5. What type of project is it?

1. Hardware or software roll-out (internal or third party) - You might be able to use a flavor of Agile if this includes software development, but COTS (Commercial Off The Shelf) rollouts tend to be straightforward (at least on the surface), with little room for iterative discovery.  Changes may go into sprints and releases, but you may be looking at an Agile influenced (hybrid) release management process, as opposed to a flavor of Agile.
2. Process change - This is not a strong candidate for a flavor of Agile.  As noted in a previous post, Scrum is not used to roll out Scrum in an organization.  Organizational change, while it may be progressive, leans toward linear change, as opposed to iterative.  This is not to say that nobody has ever made this work; it's just not a strong candidate.
3. Software or Product Development - These types of projects are often good candidates for a flavor of Agile.  Just keep the above information in mind, as well.
4. Researching/Prototyping - Discovery-type projects are the strongest candidates for a flavor of Agile.  Being able to learn, adapt, and repeat is an important part of these types of projects.

Am I missing something? Probably.  Feel free to share in the comments.

It seems like the next question should be, "What are the flavors of Agile, and which should I use?"  I'll need a little time to prepare answers for that.  Scrum and Hybrid seem to be getting the most attention, lately, but I'm not convinced that it is that simple.  Give me a few weeks to gather my thoughts on the matter.

Need free PDUs?  I'm going to let PMZilla keep you busy for a while.  I haven't checked the links, yet, but the page lists 24 ways to earn from 0.5 to 30+ PDUs.  If I come across anything significant NOT on this list, I'll let you know.

We've all heard the old maxim about what happens to you and me when assumptions are made.  Sometimes it's true, and the point is always valid - check your assumptions.  If you have even a few years work experience, however, you probably know that checking all your assumptions, before you are expected to act, isn't always feasible.

Assumptions are made all the time, in business.  They range from how someone will perform or act, to pricing and demand for a product, to what people know and need to know, to how processes are performed, and lots of places in between.  Even when best efforts are made to turn assumptions into inferences into something closely resembling facts, we still get it wrong, sometimes.  No matter how good our research is, we are still predicting outcomes and have the potential to have missed or misinterpreted one or more variables; we are still at risk of failure.

How does this apply to projects?  Have you ever assumed that requirements were complete and accurate, or that somebody's work was finished and bug-free?  I hope not, but assumptions can plague projects, if not dealt with appropriately, which is why requirements and risk management are such an important part of project management.  Even if your requirements are exact and you have mitigated or transferred all identified risk, a project can still have setbacks or fail.  Some of these sources of failure are due to assumptions made before the project has even started.

• Is this the right product for the company portfolio?
• Will there be demand for the product?
• Is the company prepared to sustainably deliver the product?
• Do you have, or can you get, the right people for the project?

I'm sure there's more.  Since this is a blog about project management, I'm going to let smarter people than me deal with the first three items.  The last item, however, touches on a topic I mentioned in a previous post.  The assumptions we, as project managers, make about the people on the project directly affect the success of our project.  We often assume:

• They know how to do their job
• They provide honest and accurate estimates for what it will take to complete the work
• They understand how to effectively participate in a project

…and the list goes on.  So what can you do? 

You probably can't teach them how to do their job.  You're a project manager and may not know how to do their job.  You can help them with estimating their work, but you're limited if you don't understand their work.  You aren't likely to be able to teach one person the PMBOK, let alone the entire team, before you start a project.  But you can walk the entire team through the project approach at the beginning of a project, without causing significant delays.  By making this part of the project plan, you get everyone somewhere close to being on the same page, and give the team the opportunity to ask questions about what is expected of them.

I describe the (waterfall) project approach as follows:

• The definition of Done - how the user/customer experience will be different when the project is complete - include project deliverables, but the user/customer experience is the focus
• The phases of the project
• Phase gates for the project - how we will know we are ready to progress from one phase to the next
• The types of testing that will be needed/performed
• Stakeholders and project roles (RACI charts as needed)
• Meetings, communication, and status reporting - include frequency and owners
• Tools & Processes - requirements elicitation & management, task tracking, test automation, communication, change management, etc…

It would be great if you can have all of this put together in the beginning of the project, but that is not always possible.  You rarely have complete details at the beginning of the project, even if your projects are rolling out the same products to different customers.  When explaining the project approach, you may also have to explain how the missing pieces will be identified and who needs to help fill in the gaps.  You won't have all of the answers, yourself; knowing who can get you the information you need is one of the keys to success as a project manager.

All of the things that I describe in the project approach are things that we, as project managers, do.  What I am saying is that we need to share this information with others, and not assume that they know how the project will be run, which will help to reduce assumptions that they make about the project and what is expected of them.

There, you have my thoughts on project assumptions.  What assumptions do you make about your projects?

Free PDUs - The People and Projects Podcast:

http://www.peopleandprojectspodcast.com/index.php/resources-for-project-managers/earn-30-free-pdus.html

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.