The Power of Team Happy Hours

The Power of Virtual Teams comes from inspiring each other to do our best for each other under a common Vision.

Today, virtual teams are very common and finding ways to build stronger team bonds has become even more challenging versus direct face to face interaction.

One recent team I worked with as an Agile coach started originally working part time from the office (two days a week) and part time from home. Those two days in the office were major events that included plenty of key meetings and workshops to collaborate, address challenges and of course increase our esprit de corps, the “pride of working together”.

However, COVID-19 changed that and the team dramatically changed as we moved into a different phase of delivery, moving from playing Agile to being Agile. More than half the team joined after lock down and never met the rest of the team in person. This posed for a new challenge with building relationships that go beyond just doing your job to the best of your ability.

Our solution was simple, yet effective: have regular happy hours as a standard “virtual Agile” ceremony. Our frequency was once every two weeks on a Thursday afternoon (usually a fairly quiet time for the team with our sprints starting on a Wednesday), but can naturally have more or at a different time based on your team situation.

Some basic guidelines that we had with the happy hour:

Maximize Fun and Building Relationships

Everyone should come into the happy hour expecting to have FUN. For many, that meant stopping work, cracking open a beverage of choice and even moving to a different spot or outside away from their work area.

Keep Work Discussions to a Minimum

We have plenty of serious work discussions already. This meeting is collectively intended to be completely different, allowing everyone relax and enjoy each other.  During our early happy hours, whenever someone started talking seriously about work, other team members would steer away from that. After a few meetings, that no longer occurred.

Attendance is Optional

It’s simple: join only if you want to.  Its unreasonable to demand fun from team members by forcing them to come. If they aren’t happy being there, that can impact the rest of the team negatively, sabotaging the purpose of the meeting.

For those that did not come, they followed our Team Working Agreement to post on our primary communication tool (Microsoft Teams) that they would not be able to attend in advance.

No Set Agenda

There are plenty of virtual games and activities you can facilitate during the virtual happy hour. Just Google them. In general, we preferred keeping it open ended and ‘go with the flow’ of conversation, although we had story telling on specific topics (like craziest time with client visits) and even had a ‘virtual DJ’ during one Happy Hour, playing music by request going from Tones and I’s “Dance Monkey” to Johnny Cash’s, “Ragged Old Flag” around Independence Day.

Don’t Judge

Negativity took a back seat during these virtual happy hours. We had a client stakeholder that had brought negativity in the past and had a rule not to bring up that person’s name or anything about that person during the happy hours to avoid it becoming a venting session. Although venting can be beneficial, that was not the purpose of this happy hour, otherwise we’d call it a ‘venting hour’.

The Result

My weather-vane for the effectiveness was simple: how many team members joined and how long did they stay on?

Out of a team of nine people (Project Manager/Business Analyst, UI/UX Designer, Business Analyst, one architect, three developers and two automation engineers/testers) nearly all would come.  If less started showing up, then we would determine whether the meeting should change or be completely dropped. However, its been going on for over three months and shows no signs of fading.

I’ve now “worked myself out of a job” and proud to watch them continue to grow and improve on their own without my direct help. They still have biweekly happy hours and I plan to go to one scheduled today!

As a bonus, the picture at the top is of my team when we combined our happy hour with a surprise persona party, dressing up as personas from our product!

WFH – How to Master Working From Home

Working From Home

As the Chinese say, “May we live in Interesting Times”.  Considering the Chinese symbol for Crisis and Opportunity are the same, these are definitely interesting times.

I’ve had the privilege of working from home since 1995 when I worked for an interactive voice response (IVR) system company called Edify and had setup at my house a 4-port Dialogic PBX to develop and test those voice systems under a small load.  Back in those days, things were very different and there have been massive improvement with distributed communication since that time.

For today, my experience indicates having some basics covered to maximize your remote capabilities.  They are the following given as a “baker’s dozen”:

1. Invest in a good head set and microphone
2. Invest in a strong, reliable Internet connection
3. Test connections early and often
4. Use Video… always
5. Set up a Productive Remote Office
6. Minimize interruptions using the “Stephen King” rule
7. Over communicate
8. Set work boundaries
9. Leverage computer over phone dial-in
10. Have 1:1 meetings and small group meetings
11. Become a master of chat and “back channeling”
12. Pick up new Remote Communication Techniques
13. Start using powerful chat tools like Slack, MS Teams and Discord

---

Now here are the details:

• Invest in a good head set and microphone

I personally am pretty cheap and have a Logitech HD 1080p camera along with a Jabra “hockey puck” speaker.  A step up would be a Yeti Blue or Snowball microphone.  In any case, do NOT depend on your integrated laptop camera, speaker and mic.  They are woefully weak sauce and will make you sound like your are in a tunnel far, far away.

• Invest in a strong, reliable Internet connection

Please, just do it!

Google “speed test” and make sure your download speed is at least 20mbps.  I prefer 50mbps and even had over 200mbps when working in Chicago.  Upload speed is usually less important, but recommend at least 10mbps for that too. I currently have an ethernet cable connected to my work computer getting 60mbps both download and upload speeds.

• Test connections early and often

I recently failed here where I did not go into a scheduled online meeting five minutes early and due to a surprise, had to reschedule under a new call bridge.  Due to this, the meeting started 4 minutes late.  Multiply that by the number of participants and that’s a lot of wasted time!

If you are the meeting host, jump into the meeting 5 minutes early.  A meeting reminder will help with that.  Also, if a *new* meeting, test the bridge at least 30 minutes before to ensure all is working.

Sometimes you may have back-to-back meetings, so this isn’t possible, but attempt to test in advance for any uncertainty as much as you can.

• Use Video… always

This can be very difficult for those new to remote work, but essential to keep the communication fidelity high.  I personally had trouble doing this for years, but finally gotten used to it.  Invest in a background screen if you are embarrassed by your work environment or using virtual screen if available (Zoom has them as long as your device’s video can handle).

• Set up a Productive Remote Office

Its very important to have a comfortable chair, a quiet place and the temperature set just like you wish.  Make sure you minimize interruptions…

• Minimize interruptions using the “Stephen King” rule

One of my all-time favorite books is, “On Writing” by Stephen King.  It’s not a horror story, but more of an autobiography.  One part that will always stick in my mind is his work environment.  Stephen has a room dedicated to his work, even when he travels.  He works every day of the year even on Thanksgiving and Christmas (but works less).

His rule: when the door is closed, don’t even knock unless its an emergency.  His wife would slide food under the door so he doesn’t get disturbed for lunch.

Now we aren’t all as rich as Stephen King, so you will have to work out policies that work best with your family, but I consider the “Stephen King rule” as a goal to seek.

• Over communicate

When in a remote meeting, repeating information worth mentioning more than once since participants may miss information due to kids yelling in the background, technical brownout, spouse knocking on the door (see “Stephen King rule”) etc.  Confirm everyone heard to validate alignment.  The time lost doing this outweigh the later discovery participants missed a key message and do the wrong work.

• Set work boundaries

Included with the “Stephen King rule”, determine times you work and don’t work.  For instance, I go usually from 6am – 8pm (not that I work that whole time).  Anything outside of that time is NOT work.  I just cut off during that period.

• Leverage computer over phone dial-in

Having a separate call-in bridge is an extra step and a loss of time for each participant.  If you do the other steps, this should be a given.

• Have 1:1 meetings and small group meetings

Leaders, this is especially for you.

Get into the habit of “management by walking around” virtually via individual and small group meetings to know what’s going on and keeping a heartbeat with your team, program, division and company.  I have plenty of topics and formats to make this more productive.

• Become a master of chat and “back channeling”

Get familiar and proficient at messaging each other with group messaging (like in Skype, Zoom and Adobe Connect meetings) and “back channeling” (like with Skype, Teams and other 1:1 messaging tools) to have private feedback during an online meeting.  Learn about how to use emoticons and direct responses versus new responses versus group responses.

• Pick up new Remote Communication Techniques

Learn the power of remote communication techniques like screen sharing (that’s table stakes folks), Zoom’s breakout sessions and Google Jam Board.  Tools like Miro and PIPlanning.io can help with SAFe’s Program Increment Planning events.

• Start using powerful chat tools like Slack, MS Teams and Discord

Using chat tools like Slack, MS Teams and Discord to communicate daily thoughts and its powerful message board, chat and conference calls.  There are many great ways of connecting including having a “Water Cooler” area to allow for sharing of small talk on shared topics not related to work (such as COVID-19 although more “big talk”, right?)

A New Way to Manage Your Application Portfolio

Addressing the often overlooked and undervalued effort of rationalizing your portfolio of applications taking new concepts of Agile, Lean and DevOps.

There are many fantastic articles on Application Portfolio Management on the Internet. For instance, “How to Rationalize Your Application Portfolio” in CIO.com by Thor Olavsrud and “How to do Software Rationalization Right” by Chris Doig are a keen starting point for justifying Application Portfolio Rationalization (APR) and the process at a high level.

As Thor puts it, “application bloat” is a significant and growing problem in Enterprises. This is as true now as it ever has been, especially when companies merge and acquire each other. Thor’s example with the Alcatel/Lucent merge is an excellent case study. However, actively addressing “application bloat” is often ignored and overlooked by senior executives. Why? It’s simply not very exciting and although significant, the benefits often take major research to fully explain and realize.

Since you are reading this blog, my assumption is you recognize the significant cost in licensing, server maintenance, support and operations of outdated, overriding and colliding applications.

Chris provides a comprehensive list of common causes of application sprawl along with typical problems and ownership costs. I’ll leave you to read up on the economic pain level managing this application sprawl costs your organization every day.

MODERNIZING THE PORTFOLIO RATIONALIZATION PROCESS

Coming from the world of Project, Program and Portfolio Management, I’ve seen these Portfolio rationalizations start on the best of intent with detailed delivery plans and specification analysis, yet typically run way over budget and extended for years, crushing themselves in their own complexity and lack of clarity. They are rooted in Waterfall delivery at the top level, negatively impacting business and economic benefits. Even with that, the Return on Investment (ROI) and Total Cost of Ownership (TCO) along with other financial measurements still makes it a “net positive” expense overall.

Applying waterfall to an ocean of apps is expensive. Companies feel a significant amount of pain in the current ways of comparing business value, ownership costs and mapping. By applying today’s concepts of Agile, DevOps and Lean software delivery, there is a better way to deliver and its in funneling that ocean into smaller pools (i.e. batches). The key approach shift is to reduce the cost of delay at the portfolio, program and project levels while maximizing economic benefit. Note the value of standardizing and reducing variability is listed as “Stage 2” in the 2019 State of DevOps Report and ties directly to managing your Portfolio.

IMPLEMENTING THE PORTFOLIO RATIONALIZATION

So how to accelerate Application Portfolio Rationalization (APR) using modern Agile, Lean and DevOps (also known as DevSecOps with Security) practices?

Start with the standard concept of a governing body. This governing body would be smaller in size consisting of no larger than a standard Scrum team in size (maximum of nine people), with preference to the smaller size. Let’s call this governing body the Accelerated Portfolio Management or “APM” for short. The APM would consist of Enterprise Application Owners to handle the business side, Enterprise Architects for the technical side and an Enterprise Program Manager (or Agile Project Management Office) to handle the process side. There may be a Product Manager, Director of Technology and other roles based on your Enterprise context, but in this case, “less is more”. Invite too many people and the entire decision-making process will slow down your APR efforts and thus increase your overall costs.

Shown successful within the IT industry, especially in maintenance and support, Kanban boards helps visualize all those applications for quick assessment and perhaps more importantly, uses a pull-based system that limits the work in progress for each step progression based on meeting certain criteria. Based on the Scaled Agile Framework’s (SAFe) Lean Portfolio Management concepts, this customized Application Portfolio Kanban (APK) helps quickly focus on those most economically valuable apps first and leave the others for research later.

To promote smaller batch sizes and retain simplicity, the shown above APK would consist of five primary lanes:

1. FUNNEL

The “entire ocean” of apps start here. Only a minimum amount of research has been completed. Applications that move on to the next lane will be decided by the APM based on strategic themes and current applications identified as the most critical due to compliance, ending of support, high maintenance costs, etc.

2. REVIEW

The Review lane filters the top applications from the funnel based on set criteria formed by the APM. The focus of the Review lane centers on a quick benefits analysis via an Application Hypothesis Statement with sufficient information for the APM to compare and prioritize applications to be candidates to move on to the next APK lane. The method used combines Weighted Shortest Job First (WSJF) with appropriate categorization. Like all Kanban, a Work In Progress (WIP) limit based on the capacity of the ACE shall be maintained.

3. ANALYZE

The Analyze lane filters top candidates from the Review lane as determined by the APM. The focus of the Analyze lane centers on the costs of rationalizing the applications including a technical complexity evaluation resulting in a refined WSJF under a standard WIP limit. The APM will finalize and formally approve the applications that will be accepted into the next lane.

4. BACKLOG

The Backlog lane provide the list of Applications next approved by the APM to devote delivery effort. This does not mean work starts immediately but is in a “ready state” for a delivery team to pull once their previous work has completed. That includes all potential applications approved to be delivered within a set timeframe agreed by the business. Applications will fall under four categories:

1. Invest (new re-write under modern technology)
2. Rationalize (update for functioning on modern technology)
3. Re-platform and Retire (entirely move the application to modern technology and retire the original)
4. Retire and Shutdown (completely remove the application since its use has become outmoded)

5. DONE

To reach “Done”, the original goal and outcome hypothesis is validated for the rationalized application and used to determine the success level. This is then measured and used for learning improvement ideas for that application and full APR process itself, feedback back into improvement actions for the APM and APK process.

FINAL THOUGHTS

The Application Rationalization Portfolio process is complicated, costly and very time consuming. Enterprises often do not give APR the attention deserved since the outcome can provide high benefits and productivity while meeting typical expectations of decreasing overall portfolio costs. Often, enterprises are challenged by the sheer size and complexity of rationalizing a portfolio, especially for larger Fortune 500 corporations, so streamlining the analysis overhead by visualizing and abstracting at the right amount will accelerate results and therefore further support.

Don’t ever think APR is a “one and done”. This is a continuous effort recommended for all major enterprises!

SAFe Transformation in Consulting

Per Version One’s Thirteenth Annual State of Agile Report, Scaled Agile Framework is the current dominant leader in Scaling Agile frameworks with 30% overall adoption within the industry.  With over 500,000 trained individuals, SAFe has  definitely made an impression within product and solution delivery.

There are many case studies on Scaled Agile’s website regarding the success stories with implementations, but they are predominantly for enterprises outside of consulting or outsourcing.  Now consulting companies are supposed to “lead the change” themselves, but that first must come internally from that company.

My story is about one such company and their internal transformation. Upon reflection, the transformation followed the Kotter change model and hence I have gained even more faith in the process.  The key human factors involved are persistence and patience with a thick coating of long-term thinking.  May you find this beneficial for your organization, especially if in consulting and struggling to adopt a standard framework that best suits you.

The Kotter Change Model follows these 8 steps (note that the steps do overlap each other, but in general followed this order):

1. Create a sense of urgency

Back in 2016, our consulting services had been successful for smaller implementations, but frequently during scaled delivery, we would run into coordination challenges.  We blended our own framework for scaling at the program level, but simply scaling our current framework in a fractal nature did not reap the benefits expected and often resulted in costly mistakes and investments.  That generated a growing sense of urgency from Leadership to maintain and increase overall profitability.

2. Build a guiding coalition

In a way, we were lucky because our largest client during 2016 requested we train them on implementing SAFe at their business due to a long, trusted partnership.  That paved the way for awareness from our Leadership of the growing demand for SAFe implementation and I joined a small group of SAFe Program Consultants (SPC) as our loose coalition of change.

This was my opportunity and requested becoming an SPC and fortunately, due to combination of positive events and my persistence, was able to take the course directly at Scaled Agile (highly recommended) and become a certified SPC, interacting with the few other SPC’s at that time to grow the framework within our company.

3. Form a strategic vision and initiatives

During the formation of this loose coalition in the second half of 2016, my direct manager and I built out an overall plan of expansion.  Note for those familiar, this was before the creation of the SAFe Implementation Roadmap.  That included a webinar with Drew Jemilo of Scaled Agile covering “SAFe in 8 pictures” along with propelling the initial form of Essential SAFe within our business.  That became our starting point for further transformation initiatives and paved the way for the next step in the Kotter change model.

4. Enlist a volunteer army

 As the equivalent of the Agile Project Management Office, I led the way with internal marketing of the framework and started spreading the word about SAFe with internal webinars, frequent roundtables and office visits, recruiting those willing volunteers.  Much later, we started a SAFe Community of Practice, which ran for about six months before fading away due to lack of involvement.  My discovery was that in general, consultants were too busy so leveraged the certifications in a way to more effectively attract them.

5. Enable action by removing barriers

At the time, there were seven primary locations for this enterprise.  I interacted with the leadership of each business unit and determined which had the greatest appetite for certification training with the least risk of failure.  Fortunately, I had discovered the Scaled Agile training material was top-notch, include many “Training from the Back of the Room” activities, providing greater impact and understanding for the attendees.

6. Generate short-term wins

I began teaching SAFe courses within each business unit in early 2017.  The first internal course was highly successful and quickly expanded to other locations, especially corporate headquarters. This was a major win, but took over two years to cover all locations with a “first wave” of training due to some local leadership not believing in the value of the training as much as others.

7. Sustain acceleration

Once summer of 2017 had hit, key business units began to incorporate SAFe into their sales process and with continued support as “the SAFe guy”, SAFe consulting business grew from only 5% of total company revenue to over 25% in 2019.  That expanded with training over 350 people not only within the company but for our client base as well.  I had become the “agent of change” for all things SAFe.

8. Institute change

True change settled in when top Leadership (C-Suite) took full notice and in the summer of 2019, the CEO and VP of Delivery took Implementing SAFe training and became certified themselves.  The outcome of that training was complete adoption corporate wide by company leadership and the mandate that all consultants would take SAFe training within the company.  Of course, the transformation is never over, but now this has embedded into the full corporate culture and burns brightly with a life of its own.

Conclusion

By the end of this transformation, our journey with the Kotter Change Model had completed one revolution.  They had “learned how to fish” on their own.  This whole process took over three years to complete, not atypical for digital transformations in the industry today and very proud of the overall success achieved.

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.

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?

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

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.