You need to build rapport and remain in touch and aware of everything happening. At every stage of client development, there are different approaches and requirements. It’s important to analyze your relationships and ensure they’re successfully moving across the client-partner lifecycle. 

The lifecycle of the client-partner relationship 

Ideally, the lifecycle of a client-partner relationship begins at acquisition and continues on from there. However, not every relationship goes through every stage of development. Some will be market-based, antagonistic, and at arms’ length forever. Some have short or extremely long lifecycles, while others develop quickly (or even skip phases). 

 Once you understand the lifecycle stage of your client-partner relationships, you can begin to manage, analyze, and develop them appropriately.   

Acquire
Brand-new accounts. At this point, we know very little about them. Transactions have a market basis and are centered on product exchange and price negotiations. It is at this stage we need to determine if this account has potential. And if it does, to secure initial projects.  

Onboard
Early accounts. During onboarding, we have investigated the possibility of a relationship and formed social bonds. We must work to identify key contacts, buying personas, the decision-making process, and advocate key account status. 

Engage
Developed accounts. Here, we have an increased level of connection, inter-organizational linkages, social ties, collaborative teams, and a strong emergence of trust. Our focus is on sales, account penetration, new revenue channels, increased business volume, and hidden pain points. 

Grow
Loyal accounts. We have projects moving toward a common goal and increased interdependence. At this stage, our focus is building the partnership, focusing on process-related problems, becoming a first-tier vendor partner, and establishing undemanding offerings. 

Nurture
Partner accounts. We are extremely close to the organization. Together, we are focused on joint value creation, establishing semi-autonomous project teams, and establishing a cultural accord.  

Lights-On
Troubled accounts. We notice work stopping or slowing, lines of sight into future work has become blocked, and the relationship is leveling down. We focus on maintaining existing buyer relationships, keeping updated with industry and client news, and looking for new opportunities.

Analyzing your client-partner relationships 

Competitive advantage is achieved not just by managing individual efforts, but by managing clients. This is best done by solving their problems. The ability to solve client needs at the lowest possible cost with timely delivery is the path to entering that market. This is the end goal of the account leaders. 

When analyzing your client-partner relationships, consider:

• What stage has the account reached? 
• What is the potential for its growth?  
• What strategies can we leverage to support this account?  
• What product-line issues can we pinpoint that are a priority for this client?
• What process-related issues can we pinpoint that are a priority for the client? 

As an account leader, your goal is to appropriately advance the client-partner relationship to anticipate and suit your client’s needs. By building relationships and remaining conscientious of the client-partner relationship, you can better analyze the status of your accounts and develop them toward your mutual goals. 

Managing your client-partner relationships 

To effectively manage relationships with your customers, focus on solving specific problems associated with various levels of rapport. When trust is still being built, concentrate on projects with high impact that have lighter effort.  

At the most basic level, clients come to us to solve problems. Most times, they are trying to resolve issues related to product functionality. These are product-related issues that can be resolved with respect to performance and compliance with specifications. 

On another level, our service is integrated into our clients’ value-added process. The fit of the solution, the method of delivery, and the technology used all influence the buyer’s process. Issues related to integrating our value into the buyer’s value chain are process-related issues. 

At the highest level, customers are striving to achieve their own strategic goals in their markets. These are facilitation-related problems. Facilitation-related issues relate to aligning strategic objectives with clients, creating mutual value, building trust, and integrating systems and people. 

The post How to Effectively Manage Your Client-Partner Relationships appeared first on Big Nerd Ranch.

Every software project of sufficient age will undergo change. We cannot predict how it will change, but accepting that change will happen can improve our decision-making process. We have to ship, we have to make money – it’s a business, after all. But resources like time, money, and effort are finite; thus it’s better to be wiser and more efficient in how we spend those resources. There are ways to develop (write) software and architect (plan) code that facilitates responding to change and strengthens stewardship with stakeholders.

This article series explores a coding approach we use at Big Nerd Ranch that enables us to more easily respond to change. It will start by laying out an example and explaining why some “traditional” approaches make change-response difficult. Part 2 will introduce the approach, and Part 3 will complete it.

My app

To help illustrate and understand how we can manage change, let’s look at a simplified Contacts app. I have chosen to use the common Master-Detail style interface, with a TableViewController showing the master list of Persons. Selecting a Person shows a ViewController displaying the Person’s details. The implementation is typical and likely familiar:

import UIKit

/// My `Person` model.
struct Person {
    let name: String
}

/// Shows a single Person in detail.
class PersonViewController: UIViewController {
    var person: Person?

    // Imagine it has functionality to display the Person in detail.
}

/// Shows a master list of Persons.
class PersonsViewController: UITableViewController {
    let persons = [
        Person(name: "Fred"),
        Person(name: "Barney"),
        Person(name: "Wilma"),
        Person(name: "Betty")
    ]

    override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        let selectedPerson = persons[indexPath.row]
        // `instantiateFromStoryboard()` is poetic convenience for this example
        let personVC = PersonViewController.instantiateFromStoryboard()
        personVC.person = selectedPerson
        navigationController?.pushViewController(personVC, animated: true)
    }
    
    // Other TableView delegate and data source functions omitted for brevity
}

When my app is launched, the PersonsViewController is the initial ViewController loaded and displayed. A user can tap on a row/cell of a Person, and the app will navigate to display the details of that Person. This is a fairly common scenario in mobile apps.

Requirements change

As it is now, the app has a single view showing a list of Persons; tap a Person and the Person’s detail is shown. The product stakeholders want to expand the app to support a new feature: Groups. To support this new feature, they want a view showing a list of Persons, and when you tap a person it shows a list of the Person’s Group memberships. The app should change from a single-view UI to a tabbed-UI, with the first tab for Persons feature and the second for the Groups feature. How can we implement this change request in a manner that provides good stewardship of time, money, and resources, and also leads to a more robust, more maintainable code base?

Consider the commonalities: both tabs start by showing a list of Persons. Our PersonsViewController shows a list of Persons, so we can use it to implement both tabs, right? While it does show persons, it’s not able to satisfy our requirements: the data to display is hard-coded within the PersonsViewController, and the tight coupling to the PersonViewController doesn’t support showing Group membership.

How can we solve this?

These aren’t the solutions you’re looking for

I’ll immediately disqualify three approaches.

First, duplication. This is creating a new class, such as PersonsGroupViewController that replicates PersonsViewController in full (perhaps by select-all, copy, paste) and edits tableView(_:didSelectRowAt:) to transition to a GroupsViewController instead of PersonViewController. Duplicating code in such a manner might work but will become a maintenance nightmare to maintain essentially the same code in multiple places.

Second, subclassing. This is creating a common base class which then PersonsViewController and PersonsGroupViewController inherit from, varying just in how the didSelect is handled. This isn’t necessarily a bad option (and in some cases may be the right approach), but in addition to creating additional maintenance overhead, it’s also not quite the correct model. The display of a list of persons is the same regardless of the action taken when tapping a cell, so to subclass just to change the tap-action is a little much.

Third, to expand PersonsViewController with some sort of “behavior” or “configuration” enum such as:

class PersonsViewController: UITableViewController {
    enum SelectionMode {
        case personDetail
        case groupMembership
    }
    var selectionMode: SelectionMode
    
    override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        switch selectionMode {
        case .personDetail:
            let personVC = PersonViewController.instantiateFromStoryboard()
            navigationController?.pushViewController(personVC, animated: true)
            
        case .groupMembership:
            let groupVC = GroupsViewController.instantiateFromStoryboard()
            navigationController?.pushViewController(groupVC, animated: true)
        }
    }    
}

// when filling in tab 1…
let personsVC = PersonsViewController.instantiateFromStoryboard()
personsVC.selectionMode = .personDetail

// when filling in tab 2…
let personsVC = PersonsViewController.instantiateFromStoryboard()
personsVC.selectionMode = .groupMembership

This approach is problematic because, in addition to making the couplings tighter and more complex, it does not scale well when more modes are added. You might be tempted to think “Oh, it’s just two cases,” but remember we are trying to position the codebase to be to respond to future, and unknown, changes. The reality of codebase maintenance is that, once you establish a pattern, future developers are likely to maintain that pattern. If more changes are required, a future developer is more likely to expand the enum and lead the ViewController down the road to the ill-fated “Massive View Controller” problem.

There is a better way, which I’ll introduce in part 2.

The post Agile Software Development: Architecture Patterns for Responding to Change – Part 1 appeared first on Big Nerd Ranch.

With this rise, it can be easy to dismiss machine learning as a too-hyped tech that will fall away in a few years. In one of our recent conversations with a client they mentioned they knew “machine learning is a hot topic right now and we don’t want to get caught up in the hype.” In reality,  machine learning was the answer to their issues rather than just hype.

A lot of this confusion surfaces around the scope of machine learning. While there is a lot of hype around deep learning, it is just a subfield of machine learning. The simplest definition one can give is: if you are using statistics to solve a problem you can reasonably argue you are using machine learning to solve your problem.

Main Types

In machine learning there are two main “camps” that a method or algorithm will fall into.

Classical Machine Learning

In the world of classic machine learning a machine learning engineer / data scientist would take data and find features of interest and possible engineer new features from existing data. They would then find the best model and parameters to get the best predictions, or classifications, for new data coming in.

Popular algorithms in this field would be Logistic Regression, Naive Bayes, and Decision Tree to name a few. Solutions for the world of classic machine learning can be sentiment analysis, spam filtering, fraud detection, and forecasting. The great thing about classical methods is you can start with a small amount of data and get decent results in most cases. Enough at least to get a proof of concept up and running while more data collection takes place.

Deep Learning

If there is any hype around machine learning it is most certainly around the subfield named deep learning. This is where we use a neural network using some linear algebra and calculus to solve many of the same problems as classic machine learning. The leverage that deep learning gives us is that with enough data features, engineering is not needed. Over time the model will find commonalities in the data. This is great as it allows startups and other companies to implement machine learning models with a single data scientist or machine learning engineer instead of a full team.

Deep learning also has the ability to use what is called transfer learning. This is where we take a model from Google that is trained on all of their data, then specialize the model to look at the kind of data we are looking at. This can help lower the amount of data needed and save time in training a proof of concept model.

While the world of Deep Learning is an interesting one, many companies’ problems can be solved in the area of classical learning. Thanks to the continued drop of computer power, building platforms capable of running thousands of inferences cheaply, or even offloading this inferencing to mobile devices, is actually possible now. It is this lowering cost we are seeing more companies and startups asking how machine learning could give them a competitive advantage.

This isn’t to say that everything in the world of machine learning is going well. The compute cost needed to push the industry forward continues to increase, making it harder and more expensive to be on the bleeding edge of research. Do not let this scare you away from machine learning, though. Even new and evolving complex problems like object detections can be implemented in a proof of concept quality for what is relativity a small investment even a small startup can afford.

SubTypes

In machine learning, we have three main groups of algorithms.

Supervised

Simply defined, this kind of learning is when we give our algorithms an answer key during their training. The two main areas in this field are classification and regression.

Unsupervised

Here we are asking a model to train with no answer key and are mostly looking to find like items. There are three main areas in this subfield; Clustering (group similar items), association (find sequences), and dimension reduction (find hidden dependents).

In some systems, you will find unsupervised models grouping items so that later, when an answer is provided, the label can be applied to a group of images and a supervised model can be trained on the results. An example of this is face detectors on sites like FaceBook or Google Photos.

Reinforcement

Most of the bleeding-edge research today takes place in this field. The idea in this arena is you give AI some constraints and scoring and allow them to learn over time what is good and bad. In the world of self-driving cars this can be overly simplified as “Stay on the road +10 points, hit a curb – 20 points, ” and the agents are programmed to try and achieve a high score. While this is mostly talked about in the world of self-driving cars and games, a more realistic place to find these in the wild is automated stock trading or enterprise resource management. Although take a look at AlphaStar to see a reinforcement AI that was created by Alphabet’s Deepmind to play StarCraft against players online.

Specializations

Like in many fields there are specializations. The two main ones are computer vision and natural language processing. Currently, in the world of machine learning, natural language processing is getting the most attention. The world of chatbots and AI assistants continues to be a big area of funding for large tech companies as they try to create the ultimate helper to keep you using their system.

Computer vision itself is not to be overlooked as AR and VR continue to gain steam and on-device computer vision algorithms gain in popularity. While computer vision and natural language processing are very different in terms of what you need to know to be successful, the two paired together can create amazingly powerful tools. One that is always brought up is Google’s translator application that can not only read what is on signs but can actually put the translation over the sign, in realtime.

With the lowering cost of powerful hardware and knowledge requirements needed to create machine learning solutions, it is no surprise machine learning has been taking off in recent years. The large tech companies now have a data scientist embed on every project to see if machine learning can give each of their projects an advantage. However, you no longer need a large tech company’s R&D budget to leverage machine learning at your company. Here at Big Nerd Ranch, we are here to help, be it discovery, building proof-of-concept, or building out a production machine learning pipeline. We can give your company a competitive edge and bring delight to your application that feels like magic.

The post The Scope of Machine Learning appeared first on Big Nerd Ranch.

Since its inception, Big Nerd Ranch has fully embraced the principles, practices, and procedures derived from the Agile Manifesto and its resulting methodologies. By design, we do not adhere prescriptively to one specific methodology (i.e. Scrum, Kanban, Extreme Programming, Scaled Agile Framework, etc). Instead, we believe in maximizing the value of practices and processes of those various methodologies by mixing and matching them to fit our daily needs. We do this because we place the greatest importance on the pillars of the Agile Manifesto, rather than solely on prescriptive models of a specific methodology. We eschew formulas for intrinsic motivation, action, and collaboration. A secondary motto that drives our culture is “Bias towards action.” Transparency, dependability, and proactivity are dispositions we aspire to in combating fear, idleness, and obscurity.

Individuals and interactions over processes and tools

We understand the critical importance of working closely together. We do this by prioritizing collaboration and communication as frequently as possible–not just within the product teams, but especially with clients and stakeholders. We promote frequent and recurring practices like daily standups, bi-weekly reviews/demos, and monthly retrospectives. We value best practices like pair programming, Agile design and development collaboration, and user research. Product teams will proactively schedule one-off calls with clients to pair on determining sustainable solutions as often as necessary. In exercising these habits, we endeavor to deliver high-quality solutions the right way, on the first attempt.

Working software over comprehensive documentation

We value the practices of continuous integration and continuous deployment. We drive our product development habits towards delivering valuable builds on a highly frequent basis. We do so by promoting Agile design thinking and execution, iterating repeatedly on the product’s user interface and user interaction with our clients and product teams until designs prove valuable. Our developers practice the habit of keeping their branches small, to maintain sustainability and momentum when delivering specific features. As a result, their pull requests (PR) are easily digestible and reviewable by their teammates. This allows us to merge multiple PRs on a daily basis. It is, therefore, not unusual for us to deliver shippable builds on a weekly basis.

Customer collaboration over contract negotiation

We tell our clients that we require their frequent and collaborative partnership. As mentioned above, we will bias towards bringing our clients into critical decision points as often as necessary to ensure that they know exactly what they’re getting. We see ourselves as stewards of our clients’ time, money, and value-generating products. And, thus, we let them down if we do not consistently collaborate with them on critical design and development decisions. We understand that critical decisions impact revenue potential, and want to ensure that we are enabling our clients to realize as much success and potential as possible.

Responding to change over following a plan

We embrace the fact that requirements change because customer behaviors, segments, and markets change. Our clients partner with us because we prove that we’re reliable partners that enable the freedom of our clients to make changes as their markets change–not contractors that are given fixed requirements thrown over a 10ft wall. Being responsive, adaptive, and flexible are necessary and vital characteristics of any modern company that builds software in a rapidly changing business landscape. It is for this reason that Big Nerd Ranch wishes to lead by example.

In summary, while we accept that good processes and comprehensive documentation are necessary and important, collaborative communication and being adaptive to the changing needs of our clients are foundational to our way of building digital products.

The post Manifesting Agile at Big Nerd Ranch appeared first on Big Nerd Ranch.

When React Native Makes Sense

There are three versions of the React Native story. One says that React Native is a silver bullet that allows you to ship two apps for the price of one. Another would have you believe that React Native is the same, disappointing cross-platform novelty we’ve seen before with familiar shortcomings. The third story is the truth, and it’s somewhere in the middle. When React Native’s strengths are aligned with a project, it’s a very attractive option. The following are some questions that you can consider to determine if React Native is a good fit for your organization or project.

Are You Building an App for iOS and Android?

The biggest selling point for React Native is that you can use one codebase to ship apps on multiple platforms, so it makes sense that React Native is helpful for any organization building iOS and Android apps simultaneously. 100% code reuse between platforms isn’t common, but it is quite feasible to reuse the majority of code in an app. When reuse isn’t an option, it’s a straightforward process to write platform-specific code. So while you don’t get two apps for the price of one, you do ship features faster across platforms compared to developing two separate apps. This has positive cost implications, and it can be even more valuable for MVP apps built to answer market questions as quickly as possible.

That’s not to say that React Native is only a good choice when building two apps at the same time, though. Focusing on developing either an iOS or Android app before building its counterpart can reduce development time on the second app thanks to reusing React Native code.

What Are the Design Goals of Your App?

React Native creates truly native experiences because it allows JavaScript code to interact with native components via a mechanism known as the bridge. This is a key distinction from hybrid-app solutions built on Cordova like PhoneGap or Ionic that create the same webviews on any device that runs the app. In React Native, a button in an iOS app is the same button component that a native iOS app will use. As powerful as the bridge is, it introduces some performance limitations on React Native apps that rely heavily on animation or other computations. (That doesn’t mean React Native is a lost cause in these situations, though.) If the vision for your app doesn’t rely on extensive animations or unusually high CPU demands, building a fast, engaging native experience with React Native is an attainable goal.

Despite those concerns, there are good reasons to be optimistic about the direction React Native is going. One of the great things about working with a thriving and popular open source technology like React Native is that the limitations facing it are constantly shrinking. Facebook is working on architecture changes that will improve bridge performance, and third-party contributors are solving problems by building solutions that benefit the whole community.

Another design consideration for cross-platform apps is, how closely does the app need to adhere to platform expectations? It is certainly possible to use React Native to create a floating action button for Android users to enjoy, for example, but that requires an Android-specific solution that can’t be reused for iOS. Creating a similar feature for iOS users would require separate iOS code and design. User experience is important no matter what kind of app you’re building, so we generally recommend using platform-specific conventions. Still, it is important to keep in mind that each feature unique to a platform will also require unique code, and using React Native makes the most sense when the least amount of unique code is required.

What Is the Composition of Your Current Dev Team?

If you have dedicated iOS, Android and web teams supporting existing apps, then React Native might not close many gaps for you. For everyone else, though, React Native probably fits into your organization. Training an iOS or Android team to build React Native apps allows them to leverage their existing platform knowledge, and they’ll have an easier time picking up the platform they’re less familiar with compared to a developer without a mobile development background. For web teams, many are already comfortable building React apps and are positioned to easily make the jump to React Native development. Even web teams that don’t use React will probably learn React Native faster than they could learn Android or iOS platform tools. And if you don’t have a dev team at all, it will be easier to find JavaScript developers than anything else.

An important caveat to keep in mind is that while the majority of a codebase can be written in JavaScript and shared between Android and iOS apps, there will probably be edge-case issues that require native code and tools to solve. Fortunately, React Native makes it easy to drop into native environments. When it becomes necessary to do so, though, a native developer’s experience is invaluable.

Regardless of the team adopting React Native, developers generally find significant benefits in the framework due to tooling conveniences like hot reloading and a powerful debugger, a wealth of open-source libraries that solve problems for them and an active community striving together to build exceptional mobile apps. These elements contribute to making more effective developers who produce code quicker.

React Native has strengths and weaknesses like any other technology; using it in the appropriate situation will let its strengths shine while minimizing the impact of its weaknesses. If React Native is appealing to you because you believe it will cut your development budget in half, or that your React developers building web apps are already prepared to create flawless iOS apps, your expectations might be setting you up for disappointment. However, if you plan to build an app for Android and iOS with a new or existing team that is excited to explore new technologies, React Native could reduce development time as well as some costs.

If you have an app you’re excited about building, get in touch with us to see if React Native could be the right tool for the job.

If you’d like to know more about what adopting React Native could mean for your organization, take a look at some of these firsthand accounts from companies that decided to use React Native, for better or worse.

• Walmart
• Zynga
• Airbnb

The post When React Native Makes Sense appeared first on Big Nerd Ranch.

In November of 2018, I will be celebrating the completion of my first year in the software industry. Yes, I will get my picture on the anniversary slide of my company’s bi-weekly update from our CEO. And yes, the Director of my team will say a few words about my accomplishments (and follies, probably) during my first year. For those of you reading this, perhaps your first year in the software industry is a distant memory, or perhaps your career in the space is in its infancy, as mine is. Regardless of where you are in your journey, I want to bring you back to the very beginning and share a few invaluable skills that I have learned- and am still perfecting- as I navigate the perils of a Project Strategist at Big Nerd Ranch.

For those of you who don’t know, at BNR, the Project Strategist wears many hats. We are involved in nearly every project from sales to delivery and, along the way, we serve as scrum masters, story writers, backlog groomers, mediators, escalation points, inspectors, meeting facilitators, nudgers, follow-uppers, and a whole list of other things. At first, I assumed the apparent fluidity in our role is largely due to the range of clients that BNR serves, which spans Fortune 500 companies to local mom and pop shops. After all, how could a large, well-funded, multinational corporation suffer from the same blockers as the entrepreneur who has his life savings and a dream? And how was I, a newbie in this field and position, supposed to know which skills apply to which project?

I will admit, the roadblocks that I came to in my first few projects really threw me for loops as I tried to figure out how to uncover that golden ticket solution that would solve everything. I was exhausted after my first few months, under the impression that I would be devoting a huge amount of emotional energy to every project that I would ever manage for the unforeseeable future. My Director and team members were a powerful support system, reminding me that I’d “get the hang of it, it takes time.” But those words fall flat in the face of a deadline that you and your team cannot meet for reasons that seem out of your control. Stressful right?

However, as I continued to work with clients of different sizes, from different industries, and with different levels of understanding of software in general, I began to recognize consistent patterns in the projects I managed. In my first year, this was my Aha Moment. I was able to start asking questions before project kick-offs that would allow me to get in front of situations that were ominous but could be avoided. I could be confident in conversations with clients because my talking points were solid and focused. I could convey topics or expectations clearly and in a way that alleviated the client’s concerns. I was able to realize that my many hats are not unique to projects, but unique to the people I interact with. This is what my team was telling me, but it’s something I had to figure out on my own to believe. Our roles as Project Strategists are not that ad-hoc list of things I mentioned before, but simply “do what you have to in order to put both the client and BNR on a path to success.” When I shifted my thinking from trying to be good at everything to being excellent at a few things, I finally felt settled into my role.

So what are those few things, you ask? You’ll laugh- I was actually told what they were in my initial phone interview with my current Director. I remember asking, “What makes someone in this role successful?” and being told (in a nutshell), “This role requires you to be authoritative, proactive, inquisitive, and relational.”

At Big Nerd Ranch, the Project Strategy team builds its processes around those four concepts: authoritativeness, proactivity, inquisitiveness, and relationships. It took me a few turns up at bat to understand and apply them to my projects- they seem so vastly experiential and my teams were blocked by real, tangible, immediate things! In my next blog post, I will outline each of these characteristics, explain how Big Nerd Ranch’s Project Strategy team utilizes them to steer a project to a successful completion while providing the highest levels of client satisfaction, and share a few amusing examples of my own experiences along the way. In the meantime, I encourage all you software strategists and managers out there to reflect on your own processes and perhaps identify how at least one of these skills can improve a client relationship or unblock a project.

The post My First Year as a Project Strategist at Big Nerd Ranch, Part 1 appeared first on Big Nerd Ranch.

Sometimes things don’t always go as planned. Code breaks, servers crash, or a product doesn’t work – you know the story.

As a Product Manager, developing a deep understanding of the root problem is critical to helping you save time and money before writing code. On the rare (cough) occasion these things happen, it’s important to have processes in place for you to evaluate and prioritize these problems for your team quickly.

What are the 5 Whys?

The 5 Whys is an analysis technique borrowed from the Toyota production system that helps you get to the root cause of a problem. The idea is, if we run into a problem (ie. code breaks, server crashes), we want to get to the root cause of failure and think about what parts of the problems you’re really there to fix.

This model encourages a deep dive by simply asking “why” to the answer of a succession of questions, suggesting that behind every seemingly technical problem is actually a human error waiting to be found.

Here’s an example from The Lean Startup by Eric Ries:

Problem Statement: A new release broke key features for customers

1. Why did the release break features? Because a particular server failed.
2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
4. Why didn’t he know? Because we didn’t train the engineer.
5. Why wasn’t the engineer trained? Because we haven’t had time and there is no documentation.

In the above example, what started as a technical error, quickly turned into a training and documentation issue. Instead of simply fixing the server and moving along, the 5 Whys would call for us to make proportional investments at each stage. In other words, fix the server, change the subsystem to make it less error-prone and create better documentation to train engineers.

Using the 5 Whys Successfully

When using the 5 Whys, it is important to make sure the answer to each question of why is as specific as possible. Since there is no “true” frameworks for how this analysis is to be completed, there is a tendency to provide general explanations or rely on assumptions. Instead, make sure your answers address each problem as specific as possible.

It’s important to note that the purpose of the 5 whys isn’t to place blame, but rather to uncover the root cause of why something unexpected occurred. For now, you are looking only at how the process is performing and how it may need to be improved. Additionally, it helps a team create small, incremental steps so that the same issue doesn’t happen again.

Summary

When you encounter failures – including failures to achieve business results, process failures, or unexpected fires, using the “5 Whys” can give your team a robust understanding of a problem and its overall impact within the organization and make a proportional investments at each of the layers.

Similarly, whenever a system or process isn’t working properly, ask why 5 times and find the human error before you embark on a more in-depth approach. You’ll be able to quickly uncover blind spots, remove assumptions, and prioritize effectively.

Now it’s your turn! The next time you have a fire, instead of grabbing the water bucket, embrace your inner child and just ask why?

The post The 5 Whys for Product Managers appeared first on Big Nerd Ranch.

Have you ever wondered what goes into a mobile app that you use on your smartphone? Wonder no more! There’s no magic to the apps we use. While we won’t dive into nitty-gritty details of a mobile app’s architecture, this easy-to-understand diagram should give you a good foundation to communicate your needs with us. We’ll start with this diagram here:

Let’s describe these parts, starting from the left:

At 9 o’ clock, you’ll see Services. Services contain the business logic and data sources for the app. Apps talk to these services through an Application Programming Interface (API), which you can think of like the cord that plugged into the back of Neo’s head. When folks talk about “the cloud”, this is what they’re typically referring to. These services may be first-party (built by the app’s company), or third-party (using one or more services made by someone else).

For example, in a peer-to-peer money transfer app, the first-party service may store the user’s preferences and transaction details, while a third-party service may be responsible for processing payments.

At 10 o’clock, you’ll see Libraries. Libraries are usually third-party “packages” of code that the app’s developers use to enable specific functionality out of the box. Developers use libraries so that they don’t have to write that functionality from scratch. For example, Android and iOS have proprietary libraries for built-in operating system features that developers can take advantage of, like using the operating system’s GPS capability or the fingerprint reader.

At 2 o’clock, you’ll see the App’s Codebase. This is the code that one or more developers are writing to build the app’s features and functionality. The code will reference the services’ APIs and will include the libraries that the developers use. The code also implements the user interface and interactions that the designer builds.

At 4 o’clock, you’ll see the User Interface and Experience. Designers are responsible for the crucial task of creating the look, feel, and experience of the app, which strongly influence how the user feels about it. The designer’s work is directly coded into the codebase by the developers, as I mentioned just previously.

These parts work together to make an app that you enjoy using!

From product ideation to distribution, Big Nerd Ranch is world-renowned for building best-in-class mobile solutions. We’d be delighted to work with you on designing and building your UI, APIs, or all of it towards an app that positively impacts your business goals.

The post The Basic Parts of a Mobile App appeared first on Big Nerd Ranch.

Technology leaders share the challenges of many other business leaders who struggle to demonstrate the alignment of their function with the rest of the organization. In a November 9 webinar on The New Face of CTO/CIO: More Than the Gatekeeper of Technology hosted by Big Nerd Ranch, 100% of survey respondents admitted they could do a better job in this area. So how do we fix this?

Results are hard to measure

Sales metrics and goals have come a long way. Sure IT, Software, and Technology teams can track uptime, but that’s a lagging indicator, not a leading one. How do technology teams delivering value know that their next month (or quarter, or year) are going to be great? And, further, that they are building software and technology that enables companies to excel?

Try a Modified NPS score just for your team

One Tech Leader we interviewed uses the Net Promoter Score (NPS) question (and a slight variation) quarterly across the company to measure how well their organization is doing and thus aligning with the company’s stated goals.

This leader customized the question to their organization’s function. In the case of IT, one tech leader modified the question to say:

On a scale of 0 to 10, how likely are you to recommend this company’s software delivery method (our use of tools, trackers, and tickets) to a friend or a colleague?

This plus some open-ended feedback led to some fundamental changes on how they build apps for their company.

Tip: In the webinar we share a way to do this simply using Google Forms.

Align using a system like OKRs

More and more companies are adopting Objectives and Key Results (OKRs) to align and for good reasons: these systems allow organizations to align around big goals, focuses effort, communicates strategy accurately, and much more.

One technology leader interviewed set key results for “nudging” employees to engage in informal professional learning like watching screencasts/webinars, participating in the internal company learning management system in addition to the traditional corporate training, to align up towards an objective of the organization to encourage life-long learning.

For more tips from leaders of technology teams on aligning, be sure to check out The New Face of CTO/CIO: More Than the Gatekeeper of Technology webinar replay. Interested in discovery, design, or app development? Reach out to Big Nerd Ranch today to talk about how we can work with your team.

The post Aligning with the Rest of the Organization: A Few Tips for Tech Leaders appeared first on Big Nerd Ranch.

Big Nerd Ranch esteems code review. We’ve seen it pay off time and again. It is core to our workflow and process. If you want to experience the benefits in your team, here’s what that means in practice for everyone involved.

Leaders Set the Stage

Leaders foster a culture of review as top priority. There are good reasons for this, as elaborated by Glen D. Sanford in light of their time at Twitter. Those reasons can be summarized as:

• Keep the cache hot: The longer it takes to close out a review, the more time everyone involved has to forget what the code being reviewed was even supposed to do. Relearning that takes time. Avoiding relearning saves time.
• Keep the cycle time short: The details of code are not the only thing you can forget. A review is a discussion. If that discussion becomes drawn out, you can forget the context of the discussion around the code, as well.
• Minimize open loops/balls in the air: (Choose your preferred metaphor bingo square.) As would-be changes stack up, there’s more chance for conflicts, and more might-bes to deal with. The faster a review process completes, the sooner you convert a maybe into fact.

Authors Must Remember Their Audience

Authors need to create PRs that are intended to be reviewed.

In practice, this means:

• Keeping your PR small and coherent: A small PR means there is less code to review; a coherent PR means reduces the number of potential concerns a reviewer might have by concentrating the effect of your changes.
• Keeping your commits small and coherent: When few lines are changed per commit, you get more opportunities to explain those changes through a commit message. The commentary–to–code ratio rises, which gives you more chances to make the changes easier for your reader to understand.
• Writing commit messages that tell a readable story: Commits do not happen in isolation. Your reviewer will see the commits in order from first to last. If those commits tell a clear story of how you moved the system from point A to point B, the reviewer will have a far easier time navigating and assimilating your changes.
• Contextualizing your changes: Git can tell your reviewer which files and classes you changed. It can’t tell them why you made that change. Sure, you renamed a parameter, but why? How did you choose the new name?
• Keeping code clear: Clear code is easier to read than convoluted.

It can be instructive to compare these principles to the SOLID principles. As with the structure of code, so with the structure of changes to that code.

Reviewers Are Co-Authors

Reviewers need to take the responsibility seriously. Review is an opportunity to have a lasting effect on both code and team.

In practice, this means:

• A reviewer must know they have that responsibility: Assign someone to review a PR. Don’t just cross your fingers. GitHub’s CODEOWNERS file-glob–based auto-assignment system can automate this.
• A reviewer should aim to improve both code and coders: Code review is a valuable way to share knowledge, best practices, and style standards. For more experienced developers doing review, this is an opportunity to teach something with a very concrete context. For less experienced developers doing review, this is an opportunity to ask questions with a very concrete context.
• Asking questions can be more valuable than giving answers: Getting a review that amounts to someone ghostwriting through you can be very frustrating. But a review that elicits an unseen problem through dialogue and solves it through collaboration is exquisite.
• A reviewer should focus on the issues only a human can catch: Code formatting and layout issues should be handled by automated processes. Let formatters/beautifiers, linters, and spell checkers do their jobs. Machines aren’t going to catch redundant abstractions, missing abstractions, inverted conditions, or mixed abstraction levels within a method’s implementation. Automating what you can reduces reviewer and reviewee burden and avoids drowning valuable review comments in a sea of noisy nitpicking comments.

Reviews Are a Canary for the Whole Process

If a team feels that reviews are rubber-stamps en route to landing changes, there will be trouble. Reviews will be reduced to unwanted busy-work.

If a team is planning work without allowing time for code review, there will be trouble. Reviews will be rushed. They might convert into rubber-stamps as a way to leave breathing room for other planned work.

“Done” includes a code review. If people feel there isn’t time to review work done, then they will be landing half-baked work. Taking on less work helps here. Kanban’s limits on work-in-progress can effectively require reviews be completed to free up space for further development.

(If PRs are piling up, you are headed for a headache of merge conflicts that everyone involved will have forgotten how to resolve, never mind review. That is a warning sign in and of itself, and it can emerge with or without a review culture.)

It’s also important for people to have realistic expectations about the time review can take. Worked three days on a PR? Expect it to take at least three days to review.

Or better, don’t work for three days before submitting something to be reviewed! The adjustment in perspective from “a PR finishes everything about something” to “a PR pushes the project to a slightly better state” can take time, but it also can unlock a lot of process improvements from planning to estimating to development and testing to, yes, reviewing. Issuing a PR each day keeps the chaos at bay.

In Review

• Leaders must lead their team to prize and prioritize reviews.
• Authors must not forget their audience. More, smaller PRs written with review in mind will accelerate everything.
• Reviewers must take co-ownership. Automation can free everyone’s time to focus on real issues.
• Review is the other half of development, and it can take as much time as development.

Interested in nurturing a code review culture in your organization? Reach out to Big Nerd Ranch today to talk about how we can work with your team to raise the bar.

Thanks to my colleagues who precipitated this post and contributed content and feedback: Josh Justice, Dan Ra, and Evan McCoy.

The post Growing a Code Review Culture appeared first on Big Nerd Ranch.