The Five Best Books I Read in 2017

the five best books I read in 2017

The Five Best Books I Read in 2017

Creating these lists every year is a good reflection on the books I read, what I’d learned, and some fulfilling moments throughout the year.

Here are the five best books I read in 2017:

So Good They Can’t Ignore You, By Cal Newport

After enjoying Cal Newport’s “Deep Work” on a plane ride to Ireland in 2016, I immediately picked up “So Good They Can’t Ignore You” at the beginning of 2017.

Follow your passion is dangerous advice.” The first third of the book argues (quite well) how often people are lead astray and feel lost because they can’t find their “passion.”  From Steve Jobs to Steve Martin, Newport utilizes famous figures to demonstrate the true art of mastery, and how most people develop their passions later on into a career, rather than “following their passion.”

I’ll be honest, I’ve never been a fan of Steve Jobs. I think in the “Apple” genius, not enough attention goes to Wozniak. I think that a lot of modern “Jobs was one of the greatest leaders ever” turn a blind eye to a lot of his mistakes, issues, and arrogance Jobs had (remember he was fired from Apple at one point, the company he founded)!

While Jobs has inspired many dreamers with his talks and philosophy on following your passion, Newport points out he didn’t quite do this himself, “If you had met a young Steve Jobs in the years leading up to his founding of Apple Computer, you wouldn’t have pegged him as someone who was passionate about starting a technology company.”  Young Steve jobs was heavily into Zen, his “passion.”

He goes on to say: “If a young Steve Jobs had taken his own advice and decided to pursue work he loved, we would probably find him today as one of the Los Altos Zen Centers most popular teachers.”

This was a very motivating book, and gives a lot of practical advice in mastery, ignoring some of our social “follow your dreams” rhetoric, and creating a more fulfilling career by becoming “so good they can’t ignore you.” The book is refreshing in a saturated marketplace of “just follow your dreams, work hard, and the rest will fall into place!”

The books core message is the importance of mastery, and mastery of a field. “[Scientific breakthrougs] require that you first get to the cutting edge of your field. Only then can you see the adjacent possible beyond, the space where innovative ideas are almost always discovered.”

The Phoenix Project by Gene Kim, Kevin Behr, and Geroge Spafford

“Improving daily work is even more important than doing daily work.”

I read this book twice in 2017. The Phoenix Project is one of the best DevOps and agile books I’ve read. My business partner in J9i, Dhiren is reading this book, and I’m considering making it required reading at my company for new project managers.

This fictional book follows Bill, a newly appointed IT manager at Parts Unlimited, who has been asked to take on a project critical to the future of the business. Bill is given an unrealistic timeline, the threat of outsourcing, and no additional budget to make this happen

A mentor arrives to help Bill and the company turns around the IT department, giving anyone who has spent more than an hour in IT plenty of “been there, done that” moments, as well as providing a proper scope on the power of DevOps integration.

My favorite line in this book describes a frequent “push-pull” between the business world and the IT world:

 “It’s harder than ever to convince the business to do the right thing. They’re like kids in a candy store. They read in an airline magazine that they can manage their whole supply chain in the cloud for $499 per year, and suddenly that’s the main company initiative. When we tell them it’s not actually that easy, and show them what it takes to do it right, they disappear. Where did they go? They’re talking to their Cousin Vinnie or some outsourcing sales guy who promises they can do it in a tenth of the time and cost.”

Anyone involved in managing IT, working with IT, or who wants a better understanding of IT (and how you can fix common issues) should read this book.

The Daily Stoic by Ryan Holiday

Philosophy is stained with the stereotype of a bearded college kid using it as an excuse to annoyingly question everything. Outsiders see no practical value, and consider it something for the snide Holden Caulfield types and their asinine musing. I shared this view until a few years ago.

Stoic philosophy was introduced to me when I was reading about George Washington and his study of Stoic philosophy. At the end of the infamous winter at Valley Forge, Washing entertained his men with the production of Cato. A trail of warriors (like Marcus Aurelius), modern day football coaches and CEOs embrace the wisdom of Stoic philosophy.

The Daily Stoic gives you an insight and exercises each day of the year. The advice is real world, “Having an end in mind is no guarantee that you’ll reach it—no Stoic would tolerate that assumption—but not having an end in mind is a guarantee you won’t.”

Here were some of my favorite quotes from the book:

That’s what Seneca is reminding us. As someone who was one of the richest men in Rome, he knew firsthand that money only marginally changes life. It doesn’t solve the problems that people without it seem to think it will. In fact, no material possession will. External things can’t fix internal issues.”

When I see an anxious person, I ask myself, what do they want? For if a person wasn’t wanting something outside of their own control, why would they be stricken by anxiety?”

Our reaction is what actually decides whether harm has occurred. If we feel that we’ve been wronged and get angry, of course that’s how it will seem. If we raise our voice because we feel we’re being confronted, naturally a confrontation will ensure.”

“The mind is a muscle, and like the rest, it can be strained, overworked, even injured. Our physical health is also worn down by overcommitment, a lack of rest, and bad habits. Remember the tall tale about John Henry—the man who challenged the machine? He died of exhaustion at the end. Don’t forget that.”

“In a scene in Steven Pressfield’s classic novel about Alexander the Great, The Virtues of War, Alexander reaches a river crossing only to be confronted by a philosopher who refuses to move. “This man has conquered the world!” one of Alexander’s men shouts. “What have you done?’ The philosopher responds, with complete confidence, “I have conquered the need to conquer the world.’”

Never Split the Difference by Chris Voss

A former hostage negotiator, Voss outlines different tactics and strategies he used in negotiation. Voss points out; you can’t just split the difference with a hostage taker by allowing her to keep three hostages and give you three hostages back.

While a lot of these books take a manipulative and condescending “gotcha” tone, this book focuses on real-world techniques and using negotiation to get a fair deal for all involved, even in extreme circumstances.

“It all starts with the universally applicable premise that people want to be understood and accepted. Listening is the cheapest, yet most effective concession we can make to get there. By listening intensely, a negotiator demonstrates empathy and shows a sincere desire to understand better what the other side is experiencing.”

This book provides a lot of sage advice for anyone who wants better deals when buying a car, selling more products or services to their clients, and other day-to-day “negotiations” we find ourselves in. The focus isn’t on sleazy tactics, the focus is on helping people understand the art of peaceful and cooperative negotiation.

“What does a good babysitter sell, really? It’s not child care exactly, but a relaxed evening. A furnace salesperson? Cozy rooms for family time. A locksmith? A feeling of security. Know the emotional drivers and you can frame the benefits of any deal in language that will resonate.”

News of the World by Paulette Jiles

News of the World is a fictional set in the aftermath of the Civil War. The book follows an aging news reader (someone who travels to local town halls and reads newspapers from foreign countries) who agrees to transport a young captive of the Kiowa back to her people. Johanna is a young orphan, raised as one of the Kiowa’s own. She has forgotten the English language, tries to escape at every opportunity, and refuses to be “civilized.”

Captain Jefferson Kyle Kidd is your stereotypical Harrison Ford/Clint Eastwood “aging badass” who has lived through three wars, fought in two of them, and personifies a lone wolf.

I had never really known about or realized the children captured and raised in Native American tribes, nor known about the physiological aspects and provocative lessons they teach us:

“As Doris had said back in the Spanish Fort, all those captured as children and returned were restless and hungry for some spiritual solace, abandoned by two cultures, dark shooting stars lost in the outer heavens.”

The book is wonderfully written, with some strong characters. The overall plot and story moves along nicely, and engages you in subjects that aren’t as often topical. Some of these scars from America (the wars with the Indians, Japanese internment camps) are better explored in fictional novels detailing what it would be like to live on the other side.

“If people had true knowledge of the world perhaps they would not take up arms and so perhaps he could be an aggregator of information from distant places and then the world would be a more peaceful place. …And then he had come to think that what people needed, at bottom, was not only information but tales of the remote, the mysterious, dressed up like hard information.”

The Jay Nine Inc Development Pipeline Explained

Jay Nine, Incorporated utilizes a development process heavily based on DevOps and “Continuous Integration” principles. We’ve found that an easy way to boost the productivity and quality of our business app development is by utilizing continuous integration.

Continuous integration provides safeguards for teams—even across different time zones—to create large and complex systems with a drastically higher level of confidence and control. The apps those teams build and deploy are more efficient, providing rapid feedback on any problems we may introduce with the changes we commit.

Amazon.com says “The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.”

In essence, we want a fast flow of left-to-right from development to IT operations to the end user (customer). To maximize this flow, we need to bring small pieces of a project to production faster, using more efficient intervals of work.

For the sake of explanation, I’m referring to everything as a “task.” A task can be as small as changing the logo on a website, or as large as creating a new app from scratch.

The Deployment Pipeline

The pipeline for taking a task from production to development should be:

  1. Analyze the Requirements
    1. Seek perfect clarity on what the task at hand is
    2. Take a minute and make sure that this is a task that needs to be done properly in the first place. There is nothing worse than doing well that which not be done at all.
    3. Confirm all developers fully understand the requirements
    4. Create the test case we will run to test the task
  2. Design/Programming
    1. Task is developed and worked on
    2. Task is documented
    3. The process for testing this task is effectively passed down to QA
  3. Implementation
    1. Task is moved to the testing environment
  4. Testing/Verification
    1. QA should review the document of tests created in step 1 or step 2
    2. QA should test the task
    3. QA needs to test the task to try and break it (as a user will) not to try and make it “pass”
    4. If the test passes, it can be moved into production. QA needs to use a video to document testing the test, one that can be sent to pertinent parties to confirm the success or failure of the task
    5. If the test fails, it should go back to step 1, and repeat

The Pipeline Dissected

The first step is to “Analyze the Requirements.

We need to be sure that this is a task that needs to be done (not just some fleeting idea or “nice-to-have” that is distracting from more important tasks). The developers and builders understand with perfect clarity what the final product looks like. If they don’t, they need to.

For example, if we’re switching out the logo on a website, the test would be:  “Logo should look proper on all major devices (including phones) with no pixelation and without impacting the page load negatively.”

The philosophy dictates that the teamn needs to develop the test, first. This is a process known test-driven development. First, the developer writes a failing test, and then completes the task until the test passes. If the test doesn’t pass, the developer knows the task isn’t ready yet

The “Design/Programming” step is a fairly straightforward second step. The programmer develops the code for this task until the test written in the prior version passes. The biggest failure point here is when a junior level developer goes unchecked in creating the code for the task. Remember, it’s fundamental the task is thought of in the ecosystem of the application as a whole. In the example of updating the logo on a website, if the programmer isn’t careful they can break the elements around the logo (often either the website tabs/navigation or the phone number/contact information). The programmer needs to ensure this is done to be scalable and not break important other functionality.

Next is the “Implementation” step, where the program moves to a “staging” version of the app. This environment is a replica of the live server.

The last step is “Testing/Verification.” In this stage, a user or QA person uses the task description provided by the business, and make sure it works as intended. The goal here is not to ensure the task works.

Instead, the goal is to try and break the program.

If a QA person isn’t ruthlessly trying to break the implemented task, we can be sure the users will. Completion of this task should include an easy demo via video (which is better when working across time zones or busy schedules) and any necessary documentation needed to log a completed task.

Why is This Pipeline Important?

Fundamentally, this process must flow from left to right, and the team may find themselves spending more time than might be considered necessary on “Analyzing the Requirements.”

The environment these tasks are developed, tested, and deployed in is critical. All developers must be working in harmony to ensure full understanding of a task before it begins. There is no room for lazily investigating a task, nor room for cowboy programmers and working in silos.

All members of the team should be thinking about the project as a whole, not just some little part of the code. Identical to an assembly line, having to go back and fix a step doesn’t speed things up. It slows down production and deeply impacts the company as a whole. Here is a why, in the first stages of the process, developing tests and focusing on the end goal will minimize this downtime.

The business leaders and project managers need to question the validity of a task constantly. The leaders need to ensure the tasks are being done to benefit the end user, the final consumer of the program. There is nothing worse than doing well, that which need not be done at all.

Repetition and practice are the key steps to mastery. When we integrate this process, we require all developers to do this on even the most simple of tasks. Otherwise, it will fail in production. If the developers, QA teams, operation teams, and business executives aren’t working closely, it will exponentially increase the number of issues in the production software.

If Apple has taught users one thing, it’s that software should just work. There shouldn’t be a lot of unnecessary troubleshooting or education, a user wants the software to perform the task as they see it. The process outlined in this article helps ensure that we can deploy many tasks into production using continuous deployment principles while giving users exactly what they want (increasing the profitability of the software).

What is DevOps? How Does DevOps Improve Software Development and IT Projects?

what is devops

DevOps (a play on “Development” and “Operations) is an enterprise software development concept meant to join Development and IT operations with improved communication and collaboration between these two business units.

To the outside looking in, “IT” generally encompasses all areas related to technology, be it programmers, the guy who fixes your printer, or the guy who maintains your current systems. To the non-technical types, there is a myth that “being good with computers” means you can do any field of computing expertise.

In the medical field, if you have a vitreoretinal illness that requires a specialized surgery, you’re going to contact an ophthalmologist–not an orthopedic doctor. While the latter will likely do better than say, myself, you want someone who has studied that particular field of medicine and does it all day.

DevOps is a system that helps merge these different IT fields together, specifically focused on making sure the people who will maintain and use the application are involved in the process from start to finish. DevOps then goes a step further, with a focus on bringing an entire organization together to ship better software, more frequently.

Under a DevOps model, development and operations are no longer operating in echo-chambers and siloed. These two teams are merged together to allow engineers and different layers of expertise to work together during the entire application lifecycle, instead of just their core expertise.

The Three Ways: Principles of DevOps

DevOps is based on “Three Ways” of which all observed patterns and behaviors are structured. Unlike a more rigid system like Scrum, DevOps is much more philosophical:

From The DevOps Handbook:

The First Way enables fast left-to-right flow of work from Development to Operations to the customer. In order to maximize flow, we need to make work visible, reduce our batch sizes and intervals of work, build in quality by preventing defects from being passed to downstream work centers, and constantly optimize for the global goals.

The First Way is based on Agile/Lean production and focuses on moving bite sizes of the final product into production sooner rather than later while bringing all key players into the development cycle (from developers to project managers, and finally–the customer).

The Second Way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again, or enable faster detection and recovery.

The Third Way enables the creation of a generative, high-trust culture that supports dynamic, disciplined, and scientific approach to experimentation and risk-tasking, facilitating the creation of organizational learning, both from our successes and failures. Furthermore, by continually shortening and amplifying our feedback loops, we create ever safer systems of work and are better able to take risks and perform experiments that help us learn faster than our competition and win in the marketplace.

The Second Way & Third Way are focused on creating safer systems of work where problems can be discovered and fixed without having to go through a committee.

Similar to the leader-leader method developed by Captain Marquet. Captain Marquet was a Navy captain, responsible for developing a unique method of leadership after he gave an impossible order to his men one day.

His method developed around the philosophy of never giving another order, rather, giving an intent. So, instead of (moving back to web development) a project manager saying “create a shopping cart with products for this new website” it’s “the intent here is to create a shopping cart that women in the late 40s, affluent, can use to purchase specialized spices for their kitchen.”

Of course, this doesn’t mean that everything is left to the discretion of the developer and lower-on-the-totem-pole people, the rules of the system (i.e., the generated PDFs from this application have to look exactly like our other branded materials, or, the conversion tracking on a website needs to be functioning 100% of the time) still apply.

What is removed is the ego of the project manager, company owner, client, and other factors that have a habit of delaying projects and causing confusion. This allows for all to have a core focus on the rules of the system.

How Does DevOps Work in an Organization?

Software and the Internet have helped transform this world, and software no longer merely supports a business; it is now a fundamental aspect of every business.

As Gene Kim (one of the founders of DevOps) mentions in a Forbes article:

“…which tended to be a set of principles from which one can derive all of the observed DevOps patterns. The first is all about accelerating flow as you go from left to right, [Development] to [Operations], in the value stream. The second is the flow of feedback, how do you create effective feedback from Ops back to Dev so that when something goes wrong, you can either prevent it or detect it more quickly. The third is about creating a culture of continual learning and experimentation using the notions of high trust culture.”

In the age of digital business, the DevOps founders realized that sites with massive traffic like Google, Amazon, and Twitter, are all known for being able to do deployments (moving new features or bug fixes into production) many times a day (or even many times an hour). In order to deploy new ideas this quickly, you’re going to need a system that doesn’t break what’s already working, can be undone easily, and relies on open and honest communication with others within the organization.

As Amazon puts it:

In a similar way that physical goods companies transformed how they design, build, and deliver products using industrial automation throughout the 20th century, companies in today’s world must transform how they build and deliver software.

Working in a DevOps environment helps place the focus on constantly shipping products, features, and changes to the customers. It means that you can establish an environment where you can create feedback as quickly, cheaply, and rampantly as possible.

DevOps & Your Organization, a Few Troubles

Initially, especially for a simpler website build or smaller piece of business software, an organization may be turned off to paying for an environment of continuous deployments. A lot of companies like the idea of treating a software project like an architectural project or remodel: there is a beginning, a middle, and end–with a fixed cost and time line.

With DevOps, you’re constantly working on improving your software or product, and focused on shipping new changes and features in a rapid environment. This means that you either have staff members or an ongoing contract with a company to ensure that software is constantly being worked on, improved, and released.

Next, if DevOps is the main philosophy of an organization or project, c-suite executives, customers, and project managers begin to get spoiled and think that this means everything will be much faster to build and implement. This is rarely the case, complicated tasks will still take longer than “an afternoon” to complete.

If you’re going to completely change your application to move from the web to a desktop or iOS style application, DevOps will not get it done by the end of the day. Rather, it means that the philosophy of DevOps will be used to ensure that when you launch the application, you don’t spend the next 3 months putting out fires for angry customers and losing business.

The next issue we see a lot in implementing DevOps: dealing with egos. The human ego has a nasty way of creeping into processes and philosophies like this and losing sight of the core focus.

It is generally agreed that DevOps is about efficiently providing the customer with the best possible product. It’s not about providing the company CEO with a new website “look” two weeks after the last website was deployed because she found a new website she likes, and this is now the top priority.

It also doesn’t allow for inter-department wars, where programmers are furious because designers keep making “asinine changes” without seeing the full project picture or designer are furious that developers came back with a two week lead time on what they felt was a “simple fix.”

DevOps is all about breaking down isolation chambers, which can be extremely difficult for some organizations.

It’s Not Everything

Much like some of the other systems we’ve talked about, DevOps has attracted a lot of Zealots that exclaim this system can do everything and the kitchen sink. While DevOps is good at creating a collaborative and agile corporate culture, it is specific to how operations and development tie together to work in harmony. It should focus only on the delivery and project management of software, without trying to fit into areas it does not belong (like the overall company structure, human resources, or other similar items).

Applying the Socratic Method to “Problem Solving” in Project Management

socratic method

When utilizing the Socratic method, an instructor asks her pupils a series of questions designed to stimulate more complete thinking and insight. Applying the Socratic method forces you to look more closely at your ideas, beliefs, and assumptions.

Did you know, more data has been created in the past two years than in the entire previous history of the human race?  While the ramifications of having access to this much knowledge are still to be determined, one thing is clear: we have (at our fingertips) access to an unprecedented amount of data.

The key point of the Socratic method (that we apply to our project management systems) is using cooperative argumentative dialogue to stimulate true critical thinking. Put another way, we don’t let opinions and non-facts stand in the way of making the best decision.

In web and software development, a lot of tasks that seem like much simpler tasks are often found out to be more difficult.

Take this example of updating the design of a website:

We’ve decided we want to replace the logos, and update the website colors and schemes. We know it’s just reorganizing the home page, updating a few logos and changing the text around.

At first, this seems easy, we think it’ll take a few hours. We don’t need to do any research to see how long this took in the past (accessing our own data) or how long it took competing companies (accessing available data on the internet or other resources). We already “know.”

So we compile the necessary materials (new logo, branding guide, fonts) and we begin. Unfortunately, we find out after two hours the new format takes longer than we thought. We told the boss it’d be ready by the end of the day, but now it looks like it won’t be ready until tomorrow.

Tomorrow comes around, the new look still isn’t ready. It turns out the designers didn’t properly account for mobile websites, and the new email templates are horrific looking in Outlook. Chaos ensues.

This takes all day to correct, and the next day begins.

We’re now on the second day of a project that was supposed to only take an afternoon, and the boss mentions “even Amazon Prime could have delivered it by now!” Developers begin to worry if they’ll see their wives again (play Battlefield 1) and designers are blogging furiously about how incompetent programmers are.

No one took the time to plan the projects, with a focus on moving beyond underlying presumptions (“it’s just a simple redesign”) and finding out the real issues (“this wasn’t properly planned for across device and in different platforms”). Nor did anyone check the data we have readily available to set proper timelines.

Larger problems have a nasty habit of disguising themselves as “just a few more hours of hard work,” and unrealistic deadlines (whether hindsight or known) cause unnecessary stress and fires to put out. Couple that with the standard human ego–especially when dealing with “experts” in an industry–and you have a perfect recipe for unnecessary stress.

Enter the Socratic questioning method, and we now have a solution for solving all of our tasks:

  1. Break each task into pieces, elements, and components.
  2. Look for relationships between the components, and missing information. If we need to add a new logo to the website, do we have all of the logo sizes and files, or is it buried in some PDF?
  3. Add the simplified as tasks within the Task Tracking software (we’re currently using Asana).
  4. Check prior tasks within HubStaff (this is a  tool we use to track how long it takes people to complete a given task). If we’ve never done a task like this before, spend some time on the internet or with a trusted colleague to get a better estimate and possible task-outliers
  5. Ok, now go back and actually read all of the materials and provided project tasks. Seriously, a number of tasks that aren’t done properly because someone skimmed a PDF (“Hey, I’m the busy CEO, I don’t have time for reading memos”) is baffling. Spend 15 more minutes planning a task and save yourself hours of back-and-forth.
  6. Create a video or have a meeting to review all the tasks, ensure all developers and people responsible for the task ask the important questions (and are ready to identify and immediately point out potential constraints, bottlenecks, or failures”
  7. Check the business logic and make sure there is a point for doing this. A lot of time is wasting on people doing well what needs not be done at all

It seems there is an accepted form of professional blackmail, where experts are expected to have the answers to a question at any given moment. Let’s be honest and acknowledge this is rarely the case. Using the Socratic Method for problem solving, while taking a few extra hours, is bound to save days and weeks of headaches and “delayed projects” from affecting other areas of business.

The Pros and Cons of Scrum

pros and cons of scrum

SCRUM is an Agile framework used for working on complicated projects, generally with a close-knit team. Simply, Scrum is a project management system.

A High-Level Overview of the SCRUM system:

  • Scrum consists of three distinct roles: product owner, scrum master, and team member
  • Scrum works by setting sequential goals that must be completed in a fixed length of time (called a “Sprint”)
  • First, the product owner creates a “backlog,” which is a fancy term for a wishlist of tasks that need to be prioritized on a project. This is the set of deliverables needed for the product.
  • Second, the Scrum team conducts a sprint planning session where parts of this wishlist are broken into smaller chunks.
  • Next, the team creates a sprint backlog, plans for the implementation, and settles on a time duration (usually 1 or 2 weeks) for every sprint
  • The team gets together every day for a scrum meeting where they share daily updates and access the progress of the project. This is led by the Scrum Master
  • The product owners and stakeholders review the sprint cycle at the end to assess progress

Pros Of Scrum

What Scrum does is bring teams together to create great things. Scrum requires all project members to see the end goal and to work incrementally towards it.

Scrum is focused on creating a workable product that can be brought to market as soon as possible.

Doing sprint cycles and focusing on fixed periods of time where you bite off small bits of the project is a welcome breath of fresh air in stale and non-moving projects. It focuses on making sure the product is deliverable, not that stakeholder’s egos are met.

Having a structured system is a great starting place for getting a project organized, on track, and meeting well thought-out objectives. The product backlog and user story is a great way to avoid scope creep and egocentric decision making.

Cons

 

SCRUM is one of those systems that really requires buy-in from all different aspects of the organization. A quote from Sutherland’s book on Scrum:

“For Scrum to really take off, someone in senior management needs to understand in his bones that impediments are nearly criminal.”

At first glance, it seems crazy to believe that anyone in senior management would accept and welcome impediments to any sort of project. This assumes two things, 1., that the impediment is obvious, and not an unforeseen 2., that ego isn’t involved.

I’m sure this doesn’t happen in your organization, but some organizations we’ve worked on have hired 1 – 3 designers and spent months tweaking a design until it was perfect. “Perfect” was only defined by the COO of the organization.

Scrum really requires a revolution of culture, which can be hard for businesses. It can be even harder if there is a larger disconnect between IT and the business teams.

Even if the business understands and buys into the Scrum process, individuals can have issues. This would be someone like a middle-level sales manager or analyst. Now, they have to make User Stories instead of the documents/mock-ups/spreadsheets they were used to.

I knew a developer who took over an extremely dysfunctional engineering team with about 100 people. The first thing he did was implement Scrum. It worked incredibly well for about 2 – 3 years.

Then, it didn’t work anymore. The team had matured, the organization had become much leaner, and the process of doing Scrum was just too much. It was time for a new change.

This is something a lot of Scrum and Agile advocates don’t realize or won’t admit — Scrum is just a tool for specific applications. Scrum is not a be-all-end-all system that will solve all of your organizational issues forever.

I’m reminded of a great quote in reference to Growth Hacker Marketing and Growth Hacking: “You can’t growth hack your way out of a PR crisis.” 

These lean and mean systems everyone is talking about work in dysfunctional environments where documentation is lack, communication is poor, and there seems to be no end in sight. The goal, I feel, should be to utilize pieces of these consistently, and only rely on the main systems in specific situations.

Like all systems, Scrum creates zealots too. It creates people who spend more time focusing on how Scrum is perfection, instead of seeing the pros and cons and focusing on the business objectives at hand.

Takeaway

Scrum, and similar systems have a habit of establishing the villainy of the status quo, and as such, a lot of the zealots spend more time refusing to see any downsides of Scrum, rather than looking at it as a useful tool for specific applications.

Another great quote in Sutherland’s book on Scrum:

“Years later it occurred to me that organizations, teams, and people are all complex adaptive systems. The same things that move cells from one state to another are also what move people from one state to another. To change a cell, you first inject energy into the system. At first, there’s chaos, there seem to be no rules, everything is in flux. When you do this to organizations trying to change, people freak out. They can’t understand what’s happening. They don’t know what to do. “

Overall I feel the principles behind Scrum are very solid. When executed properly, it really is a great way to get things done in a short period of time and to get an actual working product up and running.

Think a startup or major overhaul of an existing application. Scrum does a great job of focusing on the core components (what the users will use and need) and rolling out and testing those components. It has little room for the “surprise” meeting where we need to discuss a new offering because the CEO received a sales email from a competitor.

However, with an actual working product or existing project, I think elements of Scrum (the focus on sequential goals and eliminating waste) is a fantastic mindset all organizations should strongly push for. It’s the User stories, weekly/bi-weekly sprints, and similar that create issues.

 

How We Organize Our GIT and Why

organizing git

All of the projects for Jay Nine, Inc use a very specific process in with our development projects. Everything in the project must be checked into a single version control repository: all of the code, testing scripts, database scripts, build and deploy scripts, and anything else needed to create, install, run, and test your application.

This is for several reasons, namely:

  1. This makes it so that we have a ready-to-go back up of the entire application that we can launch at a moments notice
  2. When working with a team of developers, you can easily have multiple developers working on the project without a lot of hassle

If a bug is pushed live, our team has a rule that we try to fix it for ten minutes. If, after ten minutes, we don’t have a solution, we’ll roll back to the previous version in our version control and fix it from there.

This is auto-synced with our live websites, so when we make little fixes and update, checking in the completed code will automatically update the website (allowing for continuous deployment).

The GIT folders are organized very simply like this:

  1. The “Application” folder contains all of the necessary code that comprises the application
  2. The “Database” folder contains the latest copy of the database, in an executable format to create a new database if needed
  3. The “Documents” folder contains all of the project documents on how to use the project (end user manual) and how the project code is broken down
  4. The “Publishing and Testing Scripts” folder contains all of the documentation needed to publish the application in its environment, how to test the application to make sure no core functionality is broken, and a rollback plan in case you need to roll back for any reason

This has allowed us to drastically squash live bugs, as the checks and processes in place ensure things go live safely. A common issue with the continuous roll out plan and the frequent changes to working software is when you have live bugs.

Live bugs generally mean two things:

  1. Live bugs = lost money.
  2. Live bugs = people pulling their hair out because the customer facing version of their product/software is broken. What if a key customer sees this? What is a partner of ours sees this?

The version control system we use removes this fear. On top of that, it ensures there is always a working, ready-to-go version of the software in case something really bad happens.

How We Use Asana for Task Tracking and Project Management

using asana for project management

In the late 1940s, Toyota re-imagined the approach to manufacturing and engineering, forever changing the automotive world.

This system is highly visual in nature, allowing teams to communicate more easily on work that needs to be done, and when. It standardizes cues and refines processes, and will help eliminate waste in an organization (while maximizing production).

How the Kanban System Works

The system is easy. First, we define workflow that is specific to our business. We then use a system of priority setting, to decide which pieces of work should be tackled first. Using a pull system, we pull work from a queue in a clear system so everyone can see what’s going on.

This system controls the release of work in a project, and more importantly, ensures that the most constrained resources are doing only the work that services the goal of the entire system, not just one component.

We have a board that generally has 5 or 6 different items.

 

The board has a column for each step of the workflow, and a row for each item of work. This allows us to see who is working on what, and when. Tasks are sorted in priority order.

Asana provides an excellent platform for team collaboration in the cloud, and we have customized the boards to display based on our flow:

  • Wishlist – new ideas, tasks, and “to-dos” are added to this column
  • Live Bugs –  live bugs and urgent tasks are pinned to this column
  • In Progress – when someone begins working on a task, they pull the task from either Wishlist/Live bugs and moves it to the In Progress column.
  • Waiting on Client – When a task is completed, it is submitted for approval. The project manager will check the task, then send it to the client. Upon approval from the client, the task is move to “completed.”
  • Completed – A list of completed tasks in the order they were completed.

As with Scrum and other project management systems, the “Wishlist” serves as a place to store good ideas that are brought up at the right time. These could be tasks that need to be followed up on in the future (“we need to have photography done before we can put new pictures on the website”) or tasks that are hopeful/maybes that need to go somewhere.

 

 

How We Use Checklists to Keep Our Projects on Track

using checklists for project management

Faulty memory and distraction are a particular danger in what engineers call all-or-none processes: whether running to the store to buy ingredients for a cake, preparing an airplane for takeoff, or evaluating a sick person in the hospital, if you miss just one key thing, you might as well not have made the effort at all.

-The Checklist Manifesto

In large projects with many moving parts, professionals have a lot to remember. Hundreds, sometimes even thousands of details make up a completed project.

One of the main tools we use in project management over at Jay Nine Incorporated is the simple checklist. All of our projects and tasks have checklists associated with them to confirm crucial working parts aren’t forgotten in the haze of an ongoing project.

The checklist offers the reassurance of verification while instilling a discipline for higher performance. A checklist removes the “you should have known” variable and provides a concrete explanation of the project requirements and important aspects of the project.

For example, we have a “Website Launch Checklist” that includes the following requirements:

  • Check that all basic SEO items are included
  • Confirm 301 redirects are in order
  • Ensure loading speed is normal (below 3 seconds and at least 70/100 on Google Page Speed)
  • Test the 404 Page and make sure that works
  • Test all contact forms and confirm they are working properly
  • Confirm the website has a privacy policy
  • Ensure all web servers are in the proper time zone.
  • Ensure the website works on all browsers and devices indicated in the contract

Some of these may seem trivial, some things may seem missing to the trained eye, but these are core features that we’ve seen missed in multiple projects (at both our company and other companies).

Checklists also serve a second purpose…

Have you ever heard the story of David Lee Roth and the contract clause of “No Brown M&M’s?”

David Lee Roth is often mocked for having a clause in his contract that stipulated he had to have a bowl of M&M’s in his dressing room–with all of the brown ones removed.

In the Checklist Manifesto, it’s explained:

“Van Halen was the first band to take huge productions into tertiary, third-level markets. We’d pull up with nine eighteen-wheeler trucks, full of gear, where the standard was three trucks, max. And there were many, many technical errors—whether it was the girders couldn’t support the weight, or the flooring would sink in, or the doors weren’t big enough to move the gear through. The contract rider read like a version of the Chinese Yellow Pages because there was so much equipment, and so many human beings to make it function.’ So just as a little test, buried somewhere in the middle of the rider, would be article 126, the no-brown-M&M’s clause. “When I would walk backstage, if I saw a brown M&M in that bowl,” he wrote, “well, we’d line-check the entire production. Guaranteed you’re going to arrive at a technical error… Guaranteed you’d run into a problem.” These weren’t trifles… The mistakes could be life threatening. In Colorado, the band found the local promoters had failed to read the weight requirements and the staging would have fallen through the arena floor.

This was a checklist. It also perfectly explains the philosophy behind using checklists in large productions:

The no-brown-M&M’s was an easy way to find larger issues under the hood. It was a quick way to determine there were serious issues before a serious issue occurs. In our checklist, If we go to a “completed” website and see that Google Analytics isn’t working we know there are bigger issues. We know the checklist wasn’t followed, and can go from there.

The checklist does not discount the importance of expertise and human input. It’s just a way to help our brains remember the trivial (but nonetheless crucial and often forgotten) pieces of an ongoing project. It’s also a way we can have multiple people with different levels of expertise working harmoniously towards “perfection” in a given task or project.

 

 

 

 

The Pains of Developing an MVP and How to Overcome Them

The fabled MVP has become the new sexy word to throw around when it’s time to develop a new application, company, or product.

MVP (or minimum viable product) is meant to achieve a concept called Product Market Fit as quickly as possible. The MVP allows for small improvements based on real feedback—as opposed to  the traditional school of thought,  which is to try to launch publicly with what we think is our final, perfected product.

Think the quiet and inexpensive growth of Airbnb vs the giant release of the first iPhone.

While the concept of the MVP is a great concept, and it does work very well when executed properly, proper execution is extremely difficult. I’ve found there are generally 3 killers:

Ego Trumps All

A lot of people’s ego get in the way of the process. They want the software or the website to be “perfect” in their eyes, without really a care to the consumer.

When this is brought up, the response is usually, “oh, I know what the consumer wants.” Followed by endless meetings trying to justify why no one is buying the product or using the fancy new app.

The problem is a lot of people have issues with putting something out into the wild that they don’t deem as perfect. They chase down rabbit holes looking at issues that defeat the whole purpose of doing the MVP process in the first place.

A graph at the end of this article shows the concept of MVP a bit better too.

I’ve seen several situations where the owner of a start up developing an MVP basically ignored all of the consumer feedback (either justifying how it wasn’t the right client, or justifying how it was a one-off that wouldn’t affect the market as a whole). Instead, he only focused on his experience with the application, ruining the entire product along with it.

The Importance of Money & Time

A lot of times people hear the fantasy stories and the “cases” of Airbnb, Snapchat, or similar apps and hyper focus on the fact that it was low cost or even free (outside of time invested) to develop their app.

They then lose focus of the fact that:

  1. The exceptions are not the rule
  2. Their app isn’t nearly as revolutionary or “new” as they think it is (and definitely isn’t new to the market)

Businesses run on money. Even those one-off stories required VC or angel investment soon after they got noticed in the market. Servers need to be maintained, employees need to be paid, customers need assistance, and so on.

It’s So Misunderstood

The point of this is really quite simple:

You get a basic working version of some feature or product to the end user as fast as possible, and then continue doing that. You’re collecting validated learning experience to build consumers exactly what they want.

It’s also a methodology, not just a single product. It’s constantly working on improving and upgrading the product to fit the consumer need. This meme does a great job of explaining:

Original Image: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable by Henrik Kniberg

Why Your Software Developer Needs To Go To Sleep

“Well, you really want your IT guys [or department] to be the kind of guys that don’t have a life or girlfriend. They just sit behind their computers all day and night.”

Um, okay.

Time At Work Does NOT Equal Productive Output

I was sitting on my couch reading the other night (okay, I was playing Madden) when a solution to a software problem we’ve been trying to solve suddenly popped into my head.

We were trying to think of the best way to create a set of CSV files for a partner company to access to track some basic data entry.

While I was sitting there debating whether or not Drew Brees was going to cut it as my new franchise Quarterback, I suddenly realized that we shouldn’t be doing this with a CSV file at all, but rather (and contrary to task instructions) with a member portal.

Does this mean I should just play Madden all day? Unfortunately, no. However, if I hadn’t taken the time to rest and give my mind a break, we would have likely kept going down the road that we were “supposed” to, which wouldn’t have created the best solution for the client or their partners.

24/7 Connection Doesn’t Mean 24/7 Work-Life

This one has been written about in countless articles and books, and is becoming a more popular topic:

The obsession that our culture has with work is having a significant impact on our livelihood, families, and workplace productivity.

Just because we are now connected 24/7 doesn’t mean you should expect to hear back from someone within minutes at 9 pm (or, even 9 am).

Oh, but this issue is urgent?

In the excellent Phoenix Project book, the author says it best:

Something seems wrong in a world where half the e-mail messages sent are urgent. Can everything really be that important?

Most “urgent” issues that come across my desk are only “urgent” in the same sense that makes us pay a little more for overnight shipping.  Just because something is “wanted now” doesn’t mean it’s “urgent.”

Knowledge Workers Should Work Fewer Hours

What ends up happening is that this “developer” (the one with no life) is in front of a computer for 12 or 14 hours a day, but that doesn’t include:

  • The 90-minute lunch
  • The 2 hours spent on forums, Hacker News, Stack Overflow, or (more likely) Facebook
  • The hour-long discussion about whether or not Russia did hack the election

In a famous 1993 study of young violinists, Anders Ericsson found that the best ones all practiced the same way: in the morning, in three increments of no more than 90 minutes each, with a break between each.

He discovered the same pattern among other musicians, writers, chess players, and athletes.

I’ve found this (or a variation where you work for 55 minutes and take a 5-minute break, and then an at least an hour for lunch) is the best form of productivity. Fewer hours, but hours where you work 100% of the hours (no distractions because Aunt Sally lit up Facebook with a new fake news article).

I know, the new credo is that we need to work 80 hours a week, and be connected 24/7 in case “something comes up.”

Companies and countries encourage this mentality (more work means more productivity right?) while completely ignoring everything we scientifically know about productivity and performance.

We never challenge an executive or (really any worker) when they exclaim they’ve “worked 80 hours this week.” We accept them as someone who must be a hard worker and ignore the fact that it likely means quite the opposite.

Instead of worrying about hours in, I’d like to see a work culture that is concerned about the productivity during hours worked.