Choosing Methodologies

These days, most professionals have a few, if not several experts in their profession they follow with blogs, LinkedIn articles, tweets and any publications they make.  Outside of that, when a particular need arises, most use the typical search engine of choice to find all relevant topics to get a sufficient answer in the shortest time possible.

Well, if you ask Uncle Google or Brother Bing about how to choose a software delivery methodology, you will likely get the following:

  • Short blogs that are out of date and give fragments or partial advice
  • White papers that don’t seem to provide any clear direction (just descriptions), are out of date with current methodologies or not enough detail to truly follow

So, you are likely wondering why can’t one find that “prescription for success”.  We all realize that it’s not that easy and will never be since methodologies should be based on unique enterprises with unique engagements.  There is no such thing as a “silver bullet” in methodologies.

If you go to the sites of popular methodologies such as PMI.org, scrum.org, scrumalliance.org, Scaled Agile or Less.works to name only some, they promote their own methodology to the removal of all other options.  Even when comes to the “winning guidelines”, consulting agencies that should have the most experience providing this won’t because even though they will usually say, “we have the better methodology”, they don’t wish to give away their trade secret, since that is often one of the primary competitive differences and short of the talent of their consultants.

However, organizations all the time have tried Agile and failed.  So, why are there so many delivery failures?

That’s a huge question with a myriad of answers.  Answering that question fully is far beyond the scope of this simple blog, so will zoom the focus into process delivery, still a huge swath, but more reasonable to cover.

The main point heard by Agile Practitioners is that “Agile is easy to understand, but hard to master”.  If it was easy to master, everyone would have successfully adopted it over 15 years ago.  So some key factors as your guidelines to that mastery includes the following derived from the Agile Manifesto:

  • The process MUST ALIGN with the business
    • Don’t break the business processes, but instead transform them
  • If a methodology is followed too rigidly, it will break
    • Flexibility must be “baked” into the mindset of delivery to respond rapidly to change
    • For instance, rigidly requiring all standard scrum ceremonies without inspecting and adapting would be a poor practice
  • Never stop changing and improving
    • The global economy and hence down to your organization is always changing
    • So is your processes which must always be in flux
    • Be bold and don’t settle on only micro-changes

Often, many people within an enterprise are threatened by Agile and activity attempt to sabotage it.  This typically involves middle management and traditional project managers.  Having gone through that transition myself, I can understand the fear and uncertainty of taking a previously proven process and attempting to adopt something new, especially when it requires a fundamental change in delivery which threatens positions and one’s career.  Why would I support a new methodology if it may threaten me my job?

However, the wheels of progress inevitably rolls on and as the new generation and future employees embrace Agile methodologies, existing management will have to adjust or be forced out.  This is a fact, not a belief.

Technical Debt

Technical Debt

There are three primary types of technical debt: naïve, unavoidable and strategic.  The naïve technical debt occurs due to lack of experience or foresight, thereby resulting in poorly built software.

Unavoidable technical debt deals with improvements of tools and design patterns that can’t be utilized today, but will be available in the future.  Consider the recent release of Visual Studio 2015 July 29th along with an update of the .NET 2015 framework.  There are many improvements that were included in this release which were unavailable before and updating software to utilize the latest .NET code efficiently to avoid technical debt is likely.  Also, all thriving software systems are constantly changing and so are the development tools which will have to be updated with the waves of new changes.

Strategic technical debt is a bit different from naïve and unavoidable technical debt in that it is a business decision, not a technical challenge.

Risk Burn Down Chart

In my December blog, I covered the “Art of Risk Analysis” which skimmed over the idea of a risk burn down chart.  One of my main points is that risk review is a continuous process that should be checked on a frequent basis.  For larger projects where there are several risks, having a risk burn down chart is an excellent way to visualize the progress of closing risks but also track the level of total risk the project is experiencing from the team’s perspective.

Risk burn down charts are measured on the team’s interpretation of the expected duration a risk should last.  This duration should be updated along with the risk burn down chart during each review.  Here are my suggestions for a risk review meeting:

  • Who Leads: ScrumMaster / Project Owner
  • Who Attends: The delivery team along with the ScrumMaster.  The Product Owner is optional, but strongly encouraged to come at least to one review and obtain the results
  • When: At the start of each sprint (within a few business days).  Lasts 30 minutes unless it is the first time, then may go for an hour.
  • Goal: Update the risk register with the latest risks.  Risks should be either closed, updated or added accordingly to their current status
  • Process:
    • Setup: The ScrumMaster brings up the Risk Register (potentially blank if first time) along with the Risk Burn Down chart
    • Risk updates: ScrumMaster asks the team on updates for each existing risk.  Team is encouraged to speak up individually to obtain a consensus on each risk status
    • Risk identification: The ScrumMaster asks the team for any new risks introduced since the last update
    • Risk Review: Update the burn down chart and talk through the overall project risk level

The Risk Burn down chart should be included in status reports to management and be a topic for discussion with project sponsors and stakeholders to keep risk down to a minimum.  Keep consistency with your burn down chart with the number of risks tracked.  If you choose to have 5 risks tracked at the start of the project, keep it at 5 so trends can be equally compared.  If you believe your project risk level will be greater than your initial list, set your number to be above that list and count the missing risks as zero.  For instance, if you initially identify 7 risks but think it will increase to more than 10 in the future, make the list length 10 and count risks 8-10 as zero.

Here is an example of a Risk Register (poached from my December blog) and related Risk Burn Down chart made in MS Excel.  This is easy to create and manage although would be splendid if this was included in project management software packages like Jira, VersionOne, TFS, Rally and Pivotal Tracker to name several.

Risk Analysis

Risk Burn Down chart

You’ll see that for this project, the total sums of Expected Duration is going down, but note the burn down went up with the last sprint.  This is not unusual as new risks are discovered during the sprints.  This becomes a great communication message to leadership on whether project risk is being effectively managed.

 

Leading Indicators in Agile

Often in the world of project management, even the most experienced project managers occasionally get caught with their “pants down”.  How does that happen to even the best leaders?  Usually it involves people and their lack of communication within and beyond the team.

So how does a project manager minimize the odds of getting surprised?  Well surprises will always occur, but finding about them quickly and addressing their root causes efficiently is the behavior that is needed.  The key description heard throughout the industry is “communicate”.  We (ScrumMasters / Project Managers) hear it all the time: “Must be an excellent communicator…”  “Be an Information Radiator”, “Effective at delivering the right message”.  As one study conducted by the South Illinois University Edwardsville states, communication is the top skill to possess: http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1491&context=amcis2013

Well, communication will help manage those quite team members that may be hiding a potential land mine, but how does that communication get delivered to top leaders that don’t speak with the ScrumMaster?  My solution involves Leading Indicators.

This is a recommendation to test out the measuring of new metrics to help determine if a project is heading the wrong way before the standard metrics of schedule, budget, scope, value and quality hit into the red status.

Consider the following leading indicators:

  • Happiness (team level)
  • Code check in Ratings
  • Staff changes
  • Average overtime worked
  • Active Issues
  • Active Risks (see my article on Risk Burn Down)

These metrics can really help identify if your project is heading in the wrong direction.  My thoughts are that the process of collecting these metrics brings out the true health of the project.  Leave “no person unturned” and ensure your entire team has their input or have a delegate obtain that input for larger delivery teams.

From my experience of collecting these metrics, make sure the process is as automated as possible and that it doesn’t burden the delivery teams too much to obtain.  I find the cadence of doing once during the middle of a sprint usually works best.

Also, recommend normalizing the results so that impacts are equally noticeable for each metric.  For instance, if you are measuring happiness, set to zero if everyone is very happy and scale up if the team is very unhappy.  If you are measuring overtime, scale at a similar level to show the impact.  This is where the subjectivity comes in and would recommend having agreement by the project sponsor on how the scales should be measured.  For instance, should losing a key team member be the same weight as an unhappy team?  Should working 10 hours a week have the same impact as an average poor code check-in ratings?

Leading indicator scale

When experimenting with new ways to improve communication as reduce the risk of having an ugly project, leading indicators may yield beneficial results.  However, every project is unique and you should determine by experience or by trial whether leading indicators will help improve your delivery quality.

 

The Art of Risk Analysis

I’ve been involved in delivering projects for over twenty years now and during that time have seen the good, the bad and the ugly.  Stories of the good are sometimes brought up as “feathers in one’s cap”, the bad ones tend to be reminders of how challenging delivering projects when people, process and technology are involved but how about the ugly ones?

Those are the ones that are talked about the most and also the ones you wish to avoid at all costs.

One of the main goals for anyone leading a project is to prevent and mitigate bad events from happening even before they happen.  This should really be a goal for everyone involved in project delivery, with each person playing their part to share any news that would impact delivery to get it quickly exposed and resolved.

However, this is much harder to do than meets the eye.  One traditional way to find out when projects are heading in the right direction is to risk analysis.  Often, project leads do not spend enough time performing risk analysis activities, usually performing the activity early in the project and then spending little time afterwards, placing that much appraised “check in the box” in required activities in delivering.

Risk analysis is not considered a core part of Agile delivery, instead favoring daily stand ups to identify impediments and addressing them as they come up during the delivery cycle.  However, I’ve found few project delivery teams that don’t recognize the importance of reviewing risk independently and creating some level of a risk register as noted by Mike Cohn in his blog on Agile risks (http://www.mountaingoatsoftware.com/blog/agile-teams-and-risk-management).

There are many risk registers and recommend using the following fields and perspectives on their use.

  • Title – high level description of risk in as simple terms as possible
  • Description – Enough detail for every team member to understand, but does not include steps to solve
  • Probability – Usually given as a metric of 1 (low) to 5 (almost certain) based on 20% tier levels.  I’ve used 6 before when a risk has changed in an active issue impacting delivery.
  • Impact – Also given as a metric of 1 (low) to 5 (very high) with the same tier levels.  The product of the Probability x Impact should be your stack ranking of priority for addressing risks
  • Owner – This is often the ScrumMaster / Project Manager, similar to an impediment, but can be the team as the person who as responsible in closing the risk or with a consulting engagement may be owned by a key client member
  • Mitigation and Contingency Plans – This should include the actual steps to mitigate the risk as if it has already happened
  • Expected Duration – This should provide the estimated number of days the risk will last.  If this is a chronic risk that has been accepted as unavoidable (i.e. limited infrastructure availability so no QA environment), recommend still tracking it, but make the Expected Duration zero

Risk Analysis

Here’s the really important part.  To truly ensure proper risk management, the risk register should be reviewed on a regular basis (typically weekly but once a sprint is acceptable too).  The overall value of the register should be added up from the top 5 (or up to 10 for larger projects) and managed similarly to a product backlog.  Use the Expected Duration of those top 5 risks to measure progress in a Risk Burn chart, which will be discussed in more detail in the next blog.

Risks exist for any delivery and should be carefully reviewed and managed on a regular basis.  To ignore risks is to ignore the future of your project health.  Consider prevention and the awareness level brought by regular, organized risk reviews in order to detect and mitigate those risks before they grow and further damage the success of your delivery.

Agile is a Tool Box… and a Very Huge One at That!

Consider modern Agile as a delivery philosophy.  Here’s my hypothesis.  Agile is an approach on selecting the best tools for your culture and product.  No one set of tools or even approaches will work “best” for any given engagement.

If you don’t agree, then don’t and you can stop reading now.  It won’t hurt my feelings.  Really.  Otherwise, please take a moment and consider the state of business today.  In some ways, it hasn’t changed as much as people think.  The changes are simply faster.

Consider the ideas as stated in the Agile manifesto (http://www.agilemanifesto.org/).  For each enterprise, every project is unique where one set of tools won’t work necessarily as well as another set of tools.  It’s funny that even experts within the industry, those who have gained the title “Agile Coach” often still believe that there is a “one size fits all” strategy for companies.  That’s simply not true.

Of course, finding the right tool set for your business and project is the real challenge.  Size of the business, company culture and what is already in place take a strong play in what choices you have in choosing the tools and processes in delivering.  Also key influencers are the industry and company type you are in.  A health care company has different objectives focusing on patient privacy, security and care.  A software company focuses on bringing a product that will produce the biggest revenue base.  A consulting company looks to maximize engagements and relationships to bring the most value and profit to their client base.

Since there are a myriad of combinations, my thoughts go into the “guidelines in creating guidelines”.  I like the Mike Cohn approach to blogs and try to bring home one key idea to a blog.  This key idea is continuous improvement.  Never settle on accepting the status quo and always look for better ways to deliver.  If you are in an organization that refuses to change and you are happy with that, then this blog isn’t for you.

Best way to find out on what could be improved is to do the following:

  • Have an “experimentation mentality”
  • Read and explore new approaches
  • Follow key industry leaders
  • Fail and learn fast

These should be relatively self-evident, but I’ve been surprised time and time again how many people who are in leadership positions (and everywhere) get “caught up in their own approach” and become stuck, whether due to pride, ignorance, frustration, apathy or {choose your own emotion} and never improve.  That is the start of the end for that business and granted it is much harder for a 100 year old company to change than a 1 year old company, so it isn’t easy folks.  However, you either move ahead or fall behind.  Over the long term, there is no staying still.

Repairman Jack in Agile

Okay, so I have been an avid reader of F. Paul Wilson’s “Repairman Jack” series (http://repairmanjack.com/) finding out about it through a book club my sales executive friend, Greg Kaufman, introduced to me back in 2002.  Aside from the fact that I’ve befriended a sales person is like cats living with dogs, the book really struck me with the protagonist of the story, “Jack” was able to keep his identity unknown and blended in as an average Joe, never looking or acting like a true rock star James Bond styled hero.

Some basic things I’ve learned about Agile that many people, especially new to the practices seem to fail to understand.  First is why Agile works and second a general guidebook on how Agile should be implemented.  In Repairman Jack, Jack doesn’t fix your broken water pipe or furnace, but instead “fixes” problems in people’s lives whether it be spousal abuse or missing children.  He has his own code of honor and is flexible to situations to adapt to changes that happen in life.  He will get money up front to start, but doesn’t get paid the rest until his work is done.  There is a parallel in Agile delivery too.

Agile’s success arrives from more frequent inspection and adaption so that you know when a product is being built wrong early and change it then avoiding the tremendous costs of discovering later.  The approaches in Agile also work under the principle of the “stop starting, start finishing” mentality.  Agile will allow to have 5%, 9%, 12%, etc. of the product to be done, thereby truly having deliverable components.  They may change over time, but they are functional.  Achieving a shippable product, often called the Minimum Viable Product (MVP), is a top driving goal of Agile and should be for any product delivery too.

For companies that have mastered continuous delivery like Amazon or Google, this isn’t news.  However, what works for Amazon or Google won’t necessarily work for your business or your project.  In my next blog, I’ll cover what approaches have shown to work and not work from my experiences over 12 years practicing Agile delivery.

The PMO phoenix is reborn

In my last article, I stated that the Project Management Office (PMO) is dead.  However, I also stated long live the PMO!

In Greek mythology, the phoenix is a fiery bird that would be cyclically be reborn from its own ashes.  I believe the concepts and the principles of a Project Management Office will be reborn like a phoenix and persist through project delivery no matter what new methodology or approach becomes popular and gets adopted by today’s modern businesses.

Some examples of newer approaches to the traditional PMO are Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) and Large Scaled Scrum (LeSS). Aside from the spiffy mix of capital and lower case letters, let’s dive into their suggestions on how to run a PMO.  For this blog, I’ll first focus on SAFe.

SAFe has been gaining adoption since its inception in 2007 and has been quickly popularized due to the visual graphical interface for showing the entire methodology on one page known as the SAFe “big picture” and “diving into” each component for further detail.

SAFe is broken into three key levels: Team, Program and Portfolio.  The team level is essentially Scrum based delivery.  If you understand Scrum, you understand Team.  The Portfolio is the strategic level where company leadership management, review and prioritize the major initiatives within the organization.  The Program level is where the current portfolio of projects are collectively executed and managed.  This is where the PMO would play.

SAFe is intended for organizations that have large software delivery divisions of at 50 or more cross-functional staff, really best suited for 100 or more employees in product development teams.  SAFe does have a PMO, which are intended “to shepherd large programs from development and deployment and provide status and financial reporting.  This function may even include the responsibility for defining the enterprise’s Software Development Lifecycle (SDLC).”

This matches the traditional PMO, but changes from the “command and control” focus of the past to a lighter weight more lean approach.  However, my main point is that this is merely a rebirth of the PMO and still directly matches with the five goals mentioned in my last blog, “The PMO is dead; long live the PMO“.

Let’s take a look:

  1. Governance –  Now decentralized, so shifts now into more of a support mode, inspect and validating delivery efficiency with a focus on security, regulatory, standards, quality and release requirements
  2. Transparency – No change at all, but expected to be focused more at the team level
  3. Reusability – This is intended to keep delivery light weight and changes are more from reusable waterfall to reusable Agile artifacts, going from traditional project plans to backlogs, velocity, burn down, and Agile release schedules
  4. Delivery Support – Now supporting the Agile Release Train (ART), delivery support focusing on the quality of the releases
  5. Traceability – Under SAFe, this follow the Measures and Lifecycle Milestones with metrics on epics and budgets under regular inspection of Production Increments and Releases under SAFe

As you can see, there are differences in how the PMO is conducted to follow the SAFe delivery model, but the overall purpose and function remains the same.  So like the phoenix, the PMO is reborn!

The PMO is dead; long live the PMO!

Today, the traditional Project Management Office (PMO) is being challenged as a viable model for project governance.  Back in the day when traditional waterfall process dominated IT project delivery, the PMO was king for larger organizations.  However, even when “PMO was king”, many people within an organization would consider the PMO unnecessary overhead, calling it, “Project Management Overhead” and criticize that the PMO was a cost center, not providing enough value for the cost incurred to maintain.

With the expansion of Agile methodologies along with scaling them to a large enterprise level, the PMO has been brought under scrutiny by many pundits leading project delivery in the industry.  There are two forms recently adopted in the industry, Scaled Agile Framework (SAFe) and Large Scaled Scrum (LeSS).

One thing that should be stated first is to understand why PMO’s were formed in the first place.  Back in 1994, the Standish Group issued a report that stated over 80% of projects were either challenged or failed outright.  Clearly, that is not an acceptable success rate, unless you are batting for the Chicago White Sox.  Hence, PMO’s were born to observe and govern projects to decrease project challenges and failure.

Traditional PMO’s have the following objectives to reach that goal:

  • Governance –  Confirming the right people and right decisions are made, based on the right information
  • Transparency – Identify and address issues when they appear
  • Reusability – Providing consistency and simplicity through a single source of information
  • Delivery Support – Intended to provide project teams training, mentoring and quality assurance
  • Traceability – Track important project history for comparison and documentation to use for data mining and delivery intelligence

When it comes down to project delivery, communication is the most important factor in delivery.  Most projects fail because of lack of communication of real issues often because of lack of transparency (i.e. people are aware but keep them hidden).  Agile methodologies have helped increase transparency, thereby decreasing the ability to “hide the truth” and has therefore increased delivery success rate.

In my next blog, I’ll cover the latest ideas around PMO’s in our Agile delivery era.

The PMO is dead;  long live the PMO!

The Art of Removing Impediments

Been noticing in my career that one skill set Project Managers / Scrum Masters should master, but often don’t is the art of removing impediments.  This is not an easy skill to master and requires curiosity, courage, diplomacy, tenacity and a little bit of creativity and communication.

Often removing impediments involves connecting the right people together.  It is typically a social problem.  Yes, going to Uncle Google or Father YouTube certainly helps with any issues that plague people  the time like, “why doesn’t my OneDrive show up on Windows File Explorer”, but often with teams, these are very specific and challenging issues that won’t have an apparent answer on the grand Internet.

A true leader, whether a “command and control” leader or “servant leader” or something in between should have the curiosity to always be asking and encouraging the delivery team to bring up impediments that impact a person or the team within a short period of time.  I’ll usually state, “come see me in an hour if you and your contacts haven’t been able to figure out a solution to a given issue stopping you”.  However, the expected escalation time frame is really specific to the situation of the team, the project and the company, so use your best judgment, knowing that many team members will stretch the escalation time if they think they are close (but may actually not be even in the same planet).

Also, a project manager should have the courage to ensure the team is following the guidelines on requesting help and be willing to take ownership of resolving that issue with a high degree of urgency.  Project Managers should do anything within their power to help team members as fast as possible, but also show diplomacy, recognizing people’s time and always making them feel respected and important through the addressing the issue.  Project managers have to deal with the human microcosm of tradeoffs and ensure that those that help resolve the issue get the recognition deserved and also in turn be helped when they are in a time of need.

Tenacity is a necessary core skill a project manager must possess to resolve any team blockage as soon as possible.  Don’t ever give up, especially when you feel like it is hopeless.  There is always a solution, given enough time and thought.  That leads to creativity since the solution may require a different approach than initially expected.  The project manager should encourage the team and any parties that get involved to be educated on the nature of the issue and think through every possible path to resolve the problem.  This requires that tenacity to ensure no one feels like throwing in the towel.