jkoorsjr - Tumblr blog

[jkoorsjr]

Learn about Empathy and Healthy Routine Establishment, Keys to Leading

[jkoorsjr]

You can control every situation, no you really can! - Episode 11

[jkoorsjr]

Agile Jumpstart - Part 2, Episode 10

[jkoorsjr]

Agile Jumpstart - Part 1, Episode 9

[jkoorsjr]

Self-Managed Teams for the Win! Doug Kirkpatrick Interview

[jkoorsjr]

Agile is not all that bad, OR, is it?? - Part 2, Episode 7

[jkoorsjr]

Agile is not all that bad, OR, is it?? - Part 1, Episode 6

[jkoorsjr]

Losing Cabin Pressure Part 2 - Episode 5

[jkoorsjr]

Losing Cabin Pressure, Put on YOUR Mask First - Episode 4 pt 1

[jkoorsjr]

Authority Distribution Schema with Daniel Mezick - Episode 3

[jkoorsjr]

Scaling Agile?  This information will guide you to success.

Scaling Agile – Key Tips for Success

This was co-written by a former colleague and SAFe expert, Rene Tietsort.  I value Rene for her SAFe implementation knowledge and her practical application of Agile in real world environments.

To begin with a Scaled Agile approach, you have to understand that this is Scaled Agile Framework, which means, you have to “be Agile” and “do Agile”.  The very first sentence of the Agile Manifesto states, “We are uncovering better ways of developing software by doing it and helping others to do it.”  If I could say any one thing that is the most important is that it starts from the top.  The leadership and management must be role models and be it and do it.  These managers need not to just go through the motions, but embrace it and demonstrate Agile’s value on a daily basis.

That being said, next step of importance is to ensure you have an enterprise Agile maturity level conducive to scaling.  I would also err to say, make sure your teams are actually Agile too.  You may find that odd, but upon closer inspection of teams you’d come to realize a lot of teams and management aremerely just going through the motions or not doing it at all.

When it comes to organizational wide adoption from a leadership level, I use the scene from Buddy the Elf where he sees a café and the sign says, “World’s BEST Cup of Coffee!”.  He went in and congratulated them to receive odd looks, only later to take his date there and tell her, “This is the world’s best cup of coffee.” She informed him it’s crappy coffee.  So why did they state this on a sign outside of the café? Because it was nothing more than a self-proclamation to try and sell cheap, average coffee.  So why sell cheap, average Agile?  Start with reality, observation, analysis and use that to create the plan to get to the Agile promise land where you can reap the real benefits Agile brings.

What does assessing maturity and making sure you are Agile mean?  It basically means that everyone is onboard and your organization knows the benefits of Agile and what problems Agile is presently solving in your ecosystem.  The maturity level is defined by meeting the needs of the Agile Manifesto Values and Principles.  Are you being “Agile”, you’ll know by auditing your teams ability to meet the values and principles.  If those values and principles are being met, look at their mindset, their teaming culture, their speed to delivery and the value they are delivering.  Are they using an Agile framework and how effectively?  It’s important to note, if you have pods of resistance, chances are you will have a tough time scaling Agile because scale requires everyone to get on board with the concept.

The best thing to have on your side is someone who is a highly experienced Agilist and someone who has implemented scaled Agile in the past, with a track record of success doing so.  These individuals will assess the Agile maturity, they will detect the resistance and will know if all of your teams are truly being and doing Agile.  They will also be the concierge to help you navigate getting all teams to be Agile, working with the teams and leadership to increase the maturity and helping to mitigate the resistance from certain individuals.  Just one detractor on a team can cause an uncomfortable situation for the team and significantly slow down the Agile culture, if not bring it to a grinding halt if it’s not addressed.

Now don’t go thinking that if the planets and stars mentioned above can be aligned, someone at the executive level must make the decision to move to a Scaled Agile Framework.  This executive decision makers should empower an organizational champion that has the power to make key decisions and help remove political/bureaucratic roadblocks where necessary.  This air support is vital and the ability for this person to provide coaching and leadership as opposed to management is just as vital.  The champion must embody the same kind of transparency that are listed in the 3 Agile pillars of transparency, inspection and adaptation through very concise, organization-wide communication.  We are going to Scale Agile and for what reasons should be communicated out to everyone.  This also drives home the fact that this is a supported initiative and not something a few evangelists are trying to create a grassroots movement from.

I said people should be communicated the reasons why.  You just don’t decide to scale Agile because the company next door is doing it, or you heard that all cutting-edge tech companies are doing it.  You have to decide to scale because you have a problem or multiple problems you are trying to solve within your organization and through some research and analysis, you’ve come to realize that a Scaled Agile Framework can solve these problems.  Another action to take in solving this problem that has surfaced could be to provide a process that will mitigate the issue to allow for further analysis for a full resolution.

Now with this reason or presented set of problems, not only do you have a reason to scale Agile, but you have some measurements to determine your effort’s success levels.  I would suggest writing down these metrics of success and how you intend to measure them in an Agile way (don’t worry, your Agile expert will help you with the Agile way, which would be in the form of an information radiator of some sort that is highly transparent).

Such items might include:

·         Higher throughput

·         Faster speed to deliver

·         Improved quality, less defects

·         Less internal dependencies

·         Higher ROI, due to higher value delivered sooner

·         Improved end-user acceptance and happiness

·         Higher level understanding of initiative progress, everyone can see

There are some new concepts you will have to invest in.  First should be a shared understanding of the technology direction of the organization, governance concerns, tools and total collaboration must be understood and followed by all.   There should be a lightweight change management and escalation process that everyone understands and can quickly eliminate organizational roadblocks.  You’ll need to implement such things as Scrum of Scrums, a Scrum-of-Scrum-of-Scrums, Communities of Practice,  quarterly organization-wide planning (bi-annual at minimum) and leveraging Lean concept thinking.  As you scale, you must eliminate waste, reduce work in progress (WIP) and focus on improving cycle times.  You also must reduce the amount of time developers spend in one-off discovery sessions, consultation sessions and status update meetings they are required to attend.  (keep in mind, Scrum Ceremonies or Agile Ceremonies only take 10% or less of anyone’s time during an iteration)  We have to band together to create a distraction free, productive, and collaborative environment for the development team to operate.

One thing I would shed caution on is not to turn your head on the roles people play!  The biggest issue most organizations have in an Agile transformation is role players swimming in other’s swim lanes.  A football team doesn’t put 11 quarterbacks on the field, they don’t even put 2 quarterbacks on the field.  That 1 quarterback has a special job to do, the other players know and respect that job.   The same goes for Agile and scaled Agile.  Everyone must know and understand the roles each other are going to play and have a high level of respect for that role.  When that trust and respect is not there, this will unravel quickly.  With the help of your Agile expert and Scaled Agile expert, ensure you know the roles that are needed for scaling Agile.  Understand how  these roles help and why are they needed.

In summary, 20 things you will need to succeed (good checklist below):

1.       Get a highly experienced Agilist (organizational Agile Coach)

2.       Get someone with a track record of implementing Scaled Agile Frameworks

3.       Determine if all teams are truly Agile

4.       Assess Agile maturity, and increase teams that aren’t demonstrating Agile maturity

5.       Build the culture for it – Transparent, Safe, Courageous, Fun, Collaborative, Sans Dogma

6.       Coach, Manage or Remove Resistance

7.       Get a champion with decision making power on board for support and effective communication

      8.     Have an Agile expert and someone with experience scaling, you cannot expect someone to just read a book and do it

9.       Identify the problems you will solve by moving to scaled Agile and fully communicate

10.       Identify the metrics you will use to determine success fully explain and their benefit

11.   Identify how you will be transparent and share these metrics with everyone

12.   Have a plan (Enterprise Kanban board, Release Trains, Scrum-of-Scrums, Community of Practice, Planning Sessions, etc…)

      13.  Do Portfolio and Program level planning, create Kanban boards and keep them in an area where everyone can see them

14.   Know the roles, assign the roles, ensure all know, understand and have respect for the roles

15.   Lean focus – how will you increase focus, reduce waste, improve cycle time and throughput?

16.   Determine Lean metrics and be transparent about these as well

      17.  Determine your escalation process, ensure it is communicated and everyone knows about it

18.   Create a scaled Deming Cycle – Plan, Do, Check, Act – Someone must constantly be staying on top of this, hence, Champion, Agile Coaches and Scaled Expert – this is not set-it and forget-it

19.   Inspect, Adapt, Communicate, then Repeat at all levels (teams, leadership, and the organization)

20.   Define and implement a communication process for decisions

GOOD LUCK!!

[jkoorsjr]

Re: IT Agile DevOps Best Practices #10 - Champion and Exec Support must remain strong and committed

1 of the Agile Transformation Failure Modes is, “A checkbook or just a verbal commitment from company executive sponsorship.” If Agile and DevOps is sold on its value to deliver working software quickly with highly trusted and collaborative teams that continuously improve processes, then the team of executives and champions that encouraged this transformation must stay engaged. So, why? 1. Set it and forget it, turns into a revert or get out clause for teams 2. There are political blockers that champions and execs need to assist in removing because they are larger than the grassroots movement 3. To gather metrics and keep track on if this is really working 4. To challenge continuous improvement 5. To gauge the culture - are we fun, productive, engaging, or is the culture turning into one of revolt, cowboy coding and resistance 6. Are your role players, really doing well in their roles? 7. Are teams going through the motions, merely because they’ve been told to go through the motions 8. Are the right frameworks being used for the right reasons? 9. Are there training needs or further investments that could improve this transformation? 10. Are the tools being used to support the transition the most effective? 11. Teams reflect their leadership and role models, so if your exec team are also “being and doing” Agile, they’ll be more encouraged An Agile and DevOps transition is a 2 pronged approach. Top-Down and Bottom-Up. It has to be a culture thing, an organizational thing and it has to be supported at all times by someone that has the power to make major decisions within the company. However, don’t misconstrue this. This can go awry pretty easily if someone at the top uses too much force, makes led fist demands or supports enterprise policing of this movement. This should take place through coaching, leadership and political couth. You have to give teams discretion in the form of trust and room to operate, but you also have to build some guiderails for them to operate within. Champions and executive level continuous commitment are a huge factor in a successful Agile - DevOps organizational model.

[jkoorsjr]

Management vs Coaching

Have you know, typing in the word management, autocorrect changed it to the word enemy.

Management = the art of finding one's mistakes and commanding they correct them.

Coaching = enabling one to become self-aware of their own mistakes in which they also self-correct without command

[jkoorsjr]

Don't fear the word Fail!

Recently I’ve drawn a connection to the words failure, failed, fail and failing to demoralization of teams. This seems counterintuitive to Agile, as an Agile mindset promotes “failing fast”. If this is the mindset, then why do so many people and teams feel demoralized, a sense of loss or that they’ve let their company or management down? The answer lies in the fact that we have a trained behavior since grade school days that failing is BAD! If you were to directly call someone a failure, it’s derogatory. If you ever failed a test, you may not have passed the class or have been chided for getting that F. If you think of the longevity of time, meaning 2,000 years, failing fast has only been accepted in the last decade, maybe 2 decades. That means, 1,980 years of history knowing that any form of failing is a BAD thing. It takes a LOT to unlearn a behavior or to accept something counterintuitive as being okay, or merely a path to improvement. Take for example, the backwards bike (please watch and you’ll understand this concept a LOT better!!!) https://youtu.be/MFzDaBzBlL0 Let alone is it hard to shake the negative thought process of failure and being able to accept failure as a path to improvement at the grassroots level, but this thought process is deep rooted in managerial culture. Let me be clear, I’m not saying failure is great neither. But we must understand and get others to understand that failure is a part of learning, improving and understanding what “not to do”! So let’s define this. Fail fast should mean, pick something small, low risk, low cost and something that can be done quick. Agile promotes getting valuable things to done quick. It’s better to fail in 2 weeks, then drag a project out for 8 months to the tune of $5 million dollars and find out you failed. Agile promotes transparency, inspection and adaption. So if something did not work in the 2 week window, we essentially failed fast. When that happens, it’s time to use feedback loops, inspect why it failed, then find a way to adapt and overcome so you get better, your team gets better and ultimately your product gets better. One pitfall I commonly see is the ignoring of failure. Something didn’t work, we failed, but we move right into the next sprint or iteration and don’t change a thing, only to keep repeating this. This is not failing fast, this is just plain failing and the type of failing that does come with a negative connotation. Everything should be up for inspection and adaptation. From team size, to team resources, to the process all the way down to the tools being used. If something can prevent this vicious cycle of failing, then it must be tried and tried early. So, how do we prevent this pitfall. Good coaching! This is where coaching is important. A coach should be steadily watching, observing, listening, critical thinking and understanding what is happening. A coach should be well versed, have seen many teams and the adoption of many best practices. This coach should be savvy enough and have enough soft skills to bring the root cause of this failure to light and provide the team with the forum, environment and thought provoking knowledge that they can own a plan of action to overcome this failure themselves and overcome it early before the whole project is a failure and long before a company stands to lost a lot of big time money. Why wait? Why let it drag on for so long? Why can’t a team do this? There are high performing teams that can, but you won’t find this quality in a vast majority of teams. Most teams are too busy, too ingrained in their work, too closely attached to their work, haven’t seen best practices applied on other teams, or their main job is to code, not to navigate the political waters of the business ecosystem that will take time away from the ultimate value they were hired to do. Personally, I like to see engineers innovate, build products and ultimately build the future. I like to see Product people working with stakeholders, getting feedback from various sources, crunching numbers that indicate value vs. cost and building a backlog that drives us toward success. The safety valve to not losing money through consistent failure lies in the value of a good quality coach. So how does a coach change the mindset of the people and mindset of the team… through facts, through examples and through encouragement to pivot away from failure and point toward success. Show me any successful business mogul, athlete, celebrity or superstar and I will tell you they got where they are from not only failing, but failing many times, but using those failure to shape them, mold them and ultimately push them to the top. You want to build a culture that understands failure will happen and failure is something that we will embrace as a path to put us on a course to great success. The use of failure, the thought of the word and how it’s embraced should not be some kind of threat or scare tactic. We want to leverage this, use it as a coaching point and show people how you can take a failure and turn it into a win. If you don’t believe me, watch this other powerful clip! https://youtu.be/zLYECIjmnQs Now go out and help people and team persevere! Don’t let them quit, don’t let them feel beat up. Use this as a teaching moment to show them, that the path through failure will lead them to the finish line of success.

[jkoorsjr]

IT Agile DevOps Best Practices #9 - Build and trust in a Foundation

One of the best practices I’ve discovered as of my last assignment and has gone grossly undervalued and not leveraged to the fullest is an Agile Foundation.  What I mean by an foundation is similar to a PMO in most organizations.  It’s an enterprise level team of Agile/DevOps experts and unified vision that helps coach, encourage, train and support the adoption of Agile best practices.

They don’t go around telling everyone what to do.  They are not Agile Police and they should not be seen as some process mongering entity that is jamming a system down people’s throats.  They should be viewed more as catalysts for process improvement, positive culture change and the ability for teams to be highly productive in a very disruptive technological world.  A Foundation is here to help.

They actually build a foundation based on the backing of the Agile Alliance, Scrum Alliance and the most highly coveted best practices for the adoption process.  They follow and adopt systems that have already been proven to work, when utilized exactly as instructed of this out-of-the-box framework.  This Agile Foundation office helps teams start off right in the adoption and they are empowered to help teams make mindset changes and process changes for the better.  They promote a courageous, collaborative, creative and productive environment.

A team that is new to Agile is considered “Shu”.  The definition of Shu in Japanese that relates to Shu-Ha-Ri is the student or the beginner.  It is highly encouraged that those in the Shu spectrum adopt something prescriptive and work with someone at the Ha (Master) or Ri (Grand Master) level to begin their Agile journey.  That is where this Agile Foundation comes in.  They assist the teams and give them some best practice guiderails to make the most of their journey.

When this group is used, and used wisely, they begin to transform a team into a self-organized, highly trusted and highly productive team in the world of Agile. Agile itself isn’t the framework, it’s the mindset that this Foundation team helps cultivate.  The framework is the part of the prescriptive process that this Foundation group helps the team start with.  From there, the team will iteratively learn, retrospect and continue to improve in their adoption, flow, delivery and embracing of the Agile mindset.

So what happens when this Foundation isn’t used, there is no Foundation, or the Foundation is present, but the team uses them and their suggested approach in a la carte fashion?  The simple answer is, you do not get the full benefits of Agile.  The longer answer is, Agile will fail miserably and will start to deteriorate slowly and painfully for everyone, including the business owners of the organization.    

Let me just provide one example:  Our organization wants to be Agile and what we really like is how Agile was created to accept change “late in the process”.  A la carte is, we like change, but this process thing can stay on the buffet table.  So what happens here is a team is empowered to work with a Product Owner (representing the business) to estimate the highest priority and highest value items, then make a “COMMITMENT”.  This isn’t a “long-term” commitment.  This is a commitment that will happen in a short burst of usually 2-3 weeks.  

The best practice is to step back and have the development team honor the commitment because this is the Foundational aspect of the framework.  What happens is, the Product Owner is asked to get this new, URGENT issue done in the next 2 days.  So the Product Owner comes to the team and says, “I need you to get this done, because this is urgent and the business can’t wait and I’m told to run it through fast.”

Now, the commitment is broken.  Now, the framework and Agile everyone originally wanted, IS BROKEN.  Well, kind of… the team can easily say, let’s trade that 3 point story for another 3 point story we have in the sprint that is lower value.  OR, the team may evaluate their work and say, “We are working at a decent burn rate and can take this on without removing anything.” – This too is Agile and this too is a happy path.

It is also a slippery slope!  Rarely do I see it end here or do I see this trade-off ensue using this example of “we love change”, but not honoring Foundation best practices.  Typically, the Product Owner does this multiple times during the sprint.  Even more typically, there is no trade-off!  It is, JUST DO IT, “Oh, and by the way, I need it all done.”

It is no surprise that by the end of the sprint that stories are incomplete and points will roll over.  It is no surprise that if a team meets their original velocity commitment, it’s only 40-60% of the commitment they originally committed to.  It’s no surprise that if a team meets their velocity commitment, the developers and QA did not work at a sustainable pace and worked 60 hour work weeks and are burnt out, exhausted and would honor another gig that gave them work-life balance.  It’s no surprise that corners were cut and quality is suffering.  It’s no surprise that any of this allows the team to be consistent, repeatable and predictable so business planning can be just as consistent.

When this happens and is directly addressed by the Scrum Master or coach the typical response is, “We are just being super Agile!  We accept change, late change and this is what Agile is all about!”  

NOOOOOOO!!!!!,

Accept change late into the process with all due respect to the confines of the framework is Agile, not just accepting change anytime someone wants it spontaneously!  This is just one such example.  Of course, I have a multitude of other examples.  The Foundation safeguards what this is supposed to really be!  That is exactly what the foundation is here for – to get you the optimum benefits of Agile.  They are the checks and balances system!  They should be respected, leveraged and trusted so you can get:

Speed to deliver (high levels of productivity in short bursts)

Sustainable Pace (work life balance, high morale of team)

Consistency and Repeatability (Know the amount of work you are capable of producing and by when)

Laser Focus, Minimum WIP (Higher quality, less defects)

Innovation (giving team a bubble to innovate in and build cutting edge products)

Trust (Faith in vision, mission and culture)

The Foundation will get you to, self-directed, self-managed, highly trusted teams that are high performing.  As the teams grow and progress, they can start to change, adapt, hybridize, and in some cases create new rules when they become Ri teams.  Until all teams are Ri teams, this Foundation must exist and must encourage this movement.  What every business should want, is a development production division that can run itself!  Creating and believing in the Agile Foundation is the way to get there.  This Foundation should be a role model for the company, so if this whole Agile thing works so well, then they should demonstrate this in action!  If you are on this journey, in the middle of this journey or thinking about this journey, then you need to invest in an Agile Foundation.

It doesn’t have to be big, but it should not be small.  It should be built to scale and made so it can support the size of infrastructure you have.  These individuals are Enterprise Agile DevOps Coaches.  Team coaches (or Scrum Masters) will carry the torch at the team level.  My suggestion is 1 Enterprise Agile/DevOps Coach for every 7-10 teams.  You can stretch that to potentially 1 to every 12-14 teams, but I highly recommend 10 or less per enterprise coach.  

I would also recommend 1 coach that holds down the foundation, writes the guiderails and standards in which are all backed by the manifesto, values, principles and the original foundation in which Agile and DevOps was built on.  Teams around the company can turn to this foundation to absorb and follow these best practices.  Again, these are recommended best practices.  

Take this for example, you can probably put peanut oil in a Shelby Cobra and it will run, but not run so well.  However, if you put the high octane gasoline in that same Shelby Cobra, you’ll get the optimum performance out of that vehicle. There is no difference here in knowing what an Agile Foundation team can bring to the table!  They are the high octane gas.  So this group should merely guide, influence, coach and recommend for optimum performance.  

Get started today and build your foundation of trusted professionals and see the results you’ll get!

[jkoorsjr]

IT Agile DevOps Best Practices #8 - A Strong Leadership Triangle

This is one I’ve known existed, but it wasn’t until my latest assignment that I realized how important it is to identify and explain how these 3 important positions should work together. What is this leadership pyramid you speak of? The Product Owner, The Tech/Dev Lead, and The Team Coach/Scrum Master, These three should be firmly supported by an Enterprise Agile Coach. If these three folks aren’t on the same page, then chances are, neither will the team. By announcing this alignment, getting these 3 folks to understand the role they play, when to meet and how to work together to enhance the performance of the team, you’ll see the most optimum results. They also must fully come to an understanding of the role and value each play and use the strengths of each role for the betterment of the team. Once understood and roles are clear, the team starts to really trust them, follow their lead and get work done! These roles are vital to organizational excellence. I’ve seen this many times in my career so far. A great analogy that I recently came across in my current assignment, the Product Owner is like the CEO (the business owner and chief shot caller), the Scrum Master/Team Coach is like the COO (operation expert, best practices, lean processes, good soft-skills), the Dev Lead is like the CIO/CTO (Top gun of information technology, full stack, architect, technology decision maker). If you treat this trio as such, only the best results will happen. BUT, you have to have the best-of-the-best in these positions just like you would if you were trying to run a world-class company. There is one thing I would shed caution to. I’ve seen teams where the Dev Lead and PO were very, very good, but they thought they were so good that they could also take on the role of Scrum Master and absorb that. They watered down the Scrum Master’s involvement and skill set to the point where they Scrum Master was inconsequential, or at least that is what everyone thought. The result was 2 very stretched roles, lack of much needed soft skills and the absence of someone who was in a position to improve the productivity of the team by identifying areas where the team could progressively perform better. This doesn’t just happen with the Scrum Master. Another example I could give is where there was a strong Dev/Tech Lead and a very strong Scrum Master with a Product Owner who started to get over-shadowed. The team would take more direction from the Scrum Master and Dev Lead than the PO. Product decisions were being poorly made, stakeholder management was suffering and costs were starting to skyrocket. The same goes for when a Dev Lead gets trumped by a Scrum Master and PO… BUT, you get all 3 of these leaders firing on all cylinders, working like a cohesive team, AND sky is the limit for the team they will be leading. If I pulled the top 5 teams I’ve ever worked with, then pulled out this leadership pyramid… you would know exactly and beyond a shadow of a doubt what I’m talking about when I say this is a best practice. The power of these 3 working together should give any company executives great confidence and trust that this team will be well managed and produce superior results without the need of being hands on. I know for a fact, any company would LOVE to hire one of these PO’s, SM’s (or call this team coach), or Dev Leads. All 3 of these positions are highly valuable and best practice gold!

[jkoorsjr]

IT Agile DevOps Best Practices #7 - Tools to Succeed!

Tools to Succeed! –

I can recall a few times in my career where I was asked, “What kind of computer would you prefer?”, “Is there any special software you feel you need?” and I can also recall a few excellent managers/directors that when I approached them with a business case as to why I need a particular piece of software, tool or hardware, they said, “Let me go to bat for you.”, which they really did and it produced!  I also know this entirely allowed me to work much smarter, more organized and be much more productive in every way!

This isn’t always easy due to many constraints businesses challenge such as financial constraints, security, compliance, policy, etc… BUT, the best practice in this case isn’t just to say “NO”, decline or ignore the request.  When someone needs a tool, new machine or piece of hardware… it’s because they feel there is something about that request that will improve their daily performance.

I’m not sure if you read the book, The Phoenix Project, but if you did the lead character, Bill Palmer, mentions throughout the book about having a slow outdated laptop and his struggles with it.  Not to give away the ending, but one of the conclusions is he finally get a new laptop.  Why is this so important?  It’s important because that laptop was a thorn in his side, unreliable and caused him more setbacks that progression on the job.  Even as an executive, Bill could not get a new laptop or even drive home a business case to get one.  This didn’t prevent him from doing his job, however it limited him.

Just think about how much waste is put into a system when you have to wait extended periods of time for your computer to boot up.  Even worse, what about when it crashes, freezes or an application crashes in the middle of using it?  I worked on machines where I would type faster than what the processor could keep up with and that itself added waste to my day.  More waste is added when you don’t have the appropriate software in which case you have to find time consuming work around to almost anything you do.  Just imagine if you had to create wireframes using Microsoft Excel.  Guess what?  That was me at one point in time and I can tell you that not only was painful, but a MAJOR waste of my time.  

Not having the right software can also lead to poor communication, missed meetings or losing track of details.  Software like VPN access, email on your smartphone, good instant messaging programs, video conferencing software, and access to central shared sites/repositories are all vital parts of getting a job done with the highest levels of efficiency. If you take away any of those or sacrifice quality of any of those, you jeopardize the ability to have not only high performing individuals, but high performing teams.

The best practice here is to truly think about what everyone needs to operate at peak performance. Ask them, “Do you have all the tools necessary for success?”   Ask, “Is there any software or hardware I could provide you to make you perform on the job better?”  Let them give you their feedback and then ask for a business case.  Try to get them whatever they need to thrive.  In some cases those constraints may hold you back, but the fight is for optimum performance and higher productivity output.

I’ve worked with more tools than I care to count or imagine.  I can definitely tell you, I was at my best when I had my best set of tools (hardware and software).  I would not ask you to drive a nail with a jackhammer, nor would I ask you to drive a nail with one of those balloon hammers you get a carnival.  If a real hammer is what you need, then a real hammer is what you should get.  Teams want to succeed, not be setback by fighting with lack of quality tools all day. They already have enough challenges.

Here are some strong opinions on my experiences with certain tools (just a few):

Slack > Rocketchat > Lync/Skype

Zoom > Google Hangouts > WebEx

Sketch 3/ Adobe XD > Photoshop > Paint, Excel, PowerPoint, Elements

Gmail > Outlook

VPN, Smart Phone Email > Not having it (always keeping employees connected!!)

Mac > PC (at least the one I have now and most other one’s I have ever used)

Google Docs > OneNote

Tons of free and good code editor programs > Notepad RTF