5 Things Top Project Managers Do To Stay Organized

project managersProject managers have to juggle the needs of various team members in order to keep the whole machine running towards a company’s eventual goal. It can get very hectic, very quickly, and it’s easy to drop the ball every once and awhile. The thing is, when project managers drop said ball, they are likely setting back the overall project and letting down someone on their team.

To be an effective project manager, you have to be organized. Not JUST organized– we are talking type-A-Virgo-Batman-meets-Leslie-Knope organized. Most of us don’t have those kinds of innate organization skills on our own, though. Here are some of our best tips from top project managers on how they stay organized in order to reach their goals.

Organization Tips for Project Managers

1. Set Milestones and Expectations

Sometimes when you are on a long journey, it’s best to focus on one step at a time. If your team is all working towards a long-term goal, it’s easy for certain members to get ahead of themselves while others may become stuck getting bogged down in the details. Setting weekly or even bi-weekly milestones everyone has to work towards will create a steady pace. It will also encourage others to work as a team.

2. Communicate Often

Even if you work with a remote team, it’s important to talk as a group on a regular basis. Thanks to chat applications, it’s easier than ever to connect with those you work with. While not everybody can be plugged in for the whole 8 hours a day, set aside at least an hour a day where everyone can discuss what they are doing, questions they have, and ideas on how to improve operations.

3. Delegate Tasks

Chances are, there is someone on your team who is dying to take on something that helps them stand apart. Delegating tasks to people on your team is a great way to free up your time so you have more flexibility to address issues as needed.

4. Get Your Least Favorite Task Done First

Every day before you start the rest of your work, evaluate what needs to be done and choose your least favorite task. The first thing you should accomplish is that task. Once you have your least favorite thing completed, the rest of your day is easy in comparison.

5. Encourage Questions

When your team hesitates to ask questions, they’re more likely to complete operations in a way that requires future corrections. Being open and inviting to questions encourages the people you work with to approach you. This can help you and your team correct problems as you go, so you have a more organized process altogether.

At Number8, we help project managers connect with highly trained and efficient IT support to help reach company goals. If you’re interested in learning more about Number8 and what we do, give us a call at (502) 890-7665, or check out our information page!

Explaining the Agile Process and the Transition to an Agile Scrum Environment

agile scrumMaking the move from waterfall to an agile scrum development environment can be a big move, but for many software teams, it’s definitely worth the transition. When you work in an environment that utilizes the scrum methodology, it’s likely this organization values open communication, collaboration and efficiency.

While we’ve already explored the basics of agile scrum in previous blog posts, we haven’t delved into the actual format of agile scrum meetings. Depending on team preferences and styles, these meetings typically take on different forms and timelines, but they all include certain characteristics of the scrum methodology.

First let’s meet the “typical” agile scrum team. These are the actual people involved and engaged throughout this process. It all begins with the “Product Owner” and his or her vision for the project. Next we have the “Scrum Development Team.” This group of cross-functional members works together in a self-organizing, collective atmosphere. The “Scrum Master” is more of the team manager, providing an important type of leadershipo inside the group. The job of the Scrum Master revolves around facilitating and resolving any issues experienced throughout the entire product development process.

The Agile Process and Different Types of Agile Scrum Meetings

Now that we’ve provided a basic understanding of the team and scrum qualities, it is time to move on to the actual agile scrum process. Agile software development is often described as an incremental development process. This process becomes more of a cycle in terms of movement. If there is an issue or a setback, the process might move backward to resolve such issues. This cyclical process allows the project to easily continue forward as well. This is where the agility of this method becomes vital. But for more of a visual, the scrum process begins with the sprint planning meeting and proceeds from there. Here is an overview of the different types of scrum meetings:

Sprint Planning Meeting:

This meeting begins with the Product Owner. This is where he or she explains her vision for the project as well as ways for the team to meet this goal. During this meeting, team members decide the amount of work they can complete in a timely manner. This is also when the team moves work from the Product Backlog to the Sprint Backlog. This step requires a lot of planning and usually this takes around 8 hours for the group to decide on a finalized 30-day Sprint.

Daily Scrum and Sprint Execution:

From the planning meeting, we move into the daily scrum meetings. Every single day for about 30 minutes, the team gathers together to report any issues or progress on their tasks. Though brief, this meeting is an essential part of the scrum process. It is designed to keep all group members on track in a cohesive manner. Normally the Product Owner is present during all daily scrum meetings to assist in any way.

Sprint Review Meeting:

This meeting is used to showcase a live demonstration of the work completed. During the sprint review meeting the Product Owner, Scrum Master and stakeholders are present. They review the product and suggest changes or improvements.

Sprint Retrospective Meeting:

This meeting is held to facilitate a team’s reflection on their progress. The team speaks openly about their organizational concerns and teamwork. During this meeting, dialogue should remain friendly, non-judgmental and impartial. This review session is a key part of team building and development and it’s also very important for future scrum projects.

Backlog Refinement Meeting:

The last type of scrum meeting reviewed in this article is the backlog refinement meeting. Team members focus on the quality and skill work involved during sprints. This meeting is necessary for the business owners to connect with the development team and is used to assess the quality and development of the final product. This meeting involves important reflection on the team backlogs. These backlogs are often written in User Story form and specify what makes the product useful to the consumer.

Scrum meetings involve so much more than the brief descriptions provided above. There are many additional pieces to the scrum process including things like burndown charts and scaling, but the point of this post is to provide an overview of different kinds of scrum meetings. Regardless of the type, all scrum meetings encourage organization, progress and resolutions. With this incremental and cyclical software development process, all members have the ability to communicate openly and honestly. With the process of scrum and the sprint timeline, projects are more efficiently completed with the help of a capable and cooperative team and Product Owner led by a skillful Scrum Master.

Whether you are already using an agile approach to software development, or are considering transitioning towards a more agile methodology, the senior level agile developers at Number8 can help you make the shift. For additional details about working with a Number8 software developer, give us a call or contact us via email.

Transitioning to Agile Software Development

Agile Software Development

Business leaders are not usually concerned with the inner workings of their company’s software development– but should they be? According to the methodology of agile software development, there should be more interaction between managers and programmers.  When implemented correctly, agile development principles allow developers to stay flexible in order to build a quality project. The management side gets involved to qualify changes in deadline and anything else needed to enter the market.

Agile Software Development: Developmental Duties

When shifting towards agile software development, one major change is the amount of day-to-day duties the development team has. For one, they have to begin incorporating more QA measures in order to test developing software’s performance. It’s a dramatic shift for workers, but over time the agile software develop method will save them time with development processes.

Developers will learn to quit relying on manual testing, else they risk falling back to the previous waterfall processes. This allows them to catch bugs early on, so they can fix the software as they go. The more developed software is, the more confusing it is retracing your steps in order to find the bug.

Agile Software Development: Management Duties

The best thing a manager can do for their team when attempting to transfer to agile software development is to emphasize the importance of changing the way the team thinks as a whole. Hanging on to the old ways of developing will slow down the transition and make it more difficult to incorporate the new ways into day-to-day operations.

Managers should communicate regularly with team members. This ends up being a time intensive practice, but it’s a cornerstone of agile methodology. A main tenant for the method is people over processes. Communication is especially important because with agile, developers don’t have a defined role. Instead, they are given a certain amount of flexibility, as far as roles go. This can be pretty confusing for a manager, but it allows them to assess each team member’s strength to create more efficient processes in the future.

At Number8, we help companies transition to agile software development so they too can experience the improved processes. If you’re interested in learning more about Number8 and what we do, give us a call at (502) 890-7665, or check out our information page here!

Why Northern California Tech Companies Turn to Nearshore Outsourcing

Northern California: A National Tech Hub

The tech industry is one of the most important contributors to the Northern California economy. In order to continue developing high paying jobs, information and technology companies outsource operations to streamline processes and cut down on costs. Traditionally, Silicon Valley managers have looked to India for their outsourcing needs. However, there are various cultural issues when outsourcing to India.

Drawbacks of Offshore Outsourcing

     

  • Communication Issues – It’s hard enough translating programming concepts to clients and establishing milestones. You are bound to run into issues communicating with programmers who speak a different English dialect on top of that.
  • Time Loss – There is almost an entire day’s worth of time lost between San Francisco and Mumbai. When working with developers in India, take the loss of time into consideration when establishing project parameters. While the idea of planning a day ahead of schedule sounds great in theory, in practice we know that unexpected issues always require up-to-the-minute communication with programmers.
  • Spaghetti Programmers – The vast majority of coders in the Indian outsourcing market train to churn out work as quickly as possible. The term “spaghetti programming” refers to the code they produce; it loops round and round into a jumbled mess and if anything goes wrong, it’s very difficult to trace steps back and fix it.
  • Hidden Costs – An abundance of cheap, quick labor produces systems without structural integrity od proper checks. A system like this will eventually crash, leaving people in charge of small to medium-sized projects scrambling to fix it. Project managers end up spending the same amount of manhours they originally outsourced fixing the problem, sometimes doubling the cost of operations.

 
 

Nearshore Outsourcing: Solving Offshore Issues for Silicon Valley

 
northern californiaDespite the issues that come with offshore outsourcing, Northern California businesses still need to reach their demands for tech talent. The United States systematically fails to produce homegrown programmers and coders. Without these workers, operations halt and business growth stagnates.

Operations managers in Silicon Valley are turning to nearshore outsourcing to bridge the gap between the lack of tech talent and their business’s needs. Nearshore outsourcing finds talent in countries close to the U.S. such as Honduras and Costa Rica. There are various advantages to nearshore outsourcing.

Benefits of Nearshore Outsourcing

       

    • Smaller cultural margin – The culture in India is very hierarchical; because of this, workers tend not to take initiative on projects. They hesitate to think beyond their instructions. In many ways, the culture in Latin American culture closely aligns to that of the United States. Additionally, the English dialect studied in Central America is closer in line with that of the United States, whereas in countries like India they learn the British dialect. It may seem like a small difference, but the difference in dialect is a major barrier to effective communication.
    • Less time overlap – While there is an entire day’s difference between Silicon Valley and Mumbai, there is only an hour difference between San Francisco and Costa Rica.
    • Agile development – Nearshore programmers in Central America train in the methodology of Agile software development. Under the values and principles of agile software development, operations evolve though self-organizing cross-functional teams and collaborative effort. That means when something goes wrong, there’s no starting from scratch. Agile development is about motivated individuals working in real time and creating working software that evolves with business needs.
    • Lower costs – Nearshore combines the cost efficiency of outsourcing with the convenience of real-time communication. Higher productivity cuts down on overall costs and requires less backtracking.  Furthermore, with nearshore outsourcing, supervisors in charge of development projects are able to directly oversee their teams. Flights from Northern California to Central America are quick and relatively cheap.

     

    At Number8, we help Northern California tech businesses connect with agile software developers in Central America. Our teams–both foreign and domestic– provide cost-effective services minus the difficulties and risks that come from offshore outsourcing. If you’re interested in learning more about Number8 and what we do, give us a call at (502) 890-7665, or check out our information page here!

My Xamarin Experience

xamarinDifferent Options

When developing software, whether it’s for a fun project or a formal business project, a requirement can be met by many different options and technologies. After a while of looking at many, it is natural to think which is the best option for the requirement.

Let us consider the options for building a mobile application.

Sometimes the best option is determined by the compatibility of the implications of the option and the technical strengths of the development team. (I’ll cover implications a little later)  The first option to consider when building a mobile application are native applications, but it immediately raises a warning – when the code for a platform is done, the code will need to be transcribed to another platform.  Second, every native technology has its own implications. So to have a successful mobile experience in all native platforms, a developer for each platform is needed.

Even if there was a developer for each platform, is it worthwhile to develop a native mobile application for each platform instead of modifying a web page so it can be viewed in any device?  This is an important question to consider so here is a comparison chart for key characteristics.

CharacteristicNative ApplicationWeb Page
InternetAfter downloading the app, it can work in offline or online modeOnly works with internet connectivity
PerformanceNative components are lightweight and fastPages tend to be heavy and work somewhat slower
Push NotificationsCan send push notificationsCan’t send push notifications
Hardware AccessAccess to camera, speaker, flash, etc.Does not have access to hardware
AccessibilityOpening the app with a clickOpening browse and typing URL
User ExperienceNatural feels and smoothUnnatural and, in some cases, slow

Based on this comparison, it appears that a native application offers a wider range for creativity and service options. If the development team handles all the implications for every platform then it might be a good idea to develop a mobile app natively for each platform, considering that native applications have the best performance and assuming the business is willing to pay a higher cost.

Let’s talk more about those “implications”.


Implications

When dealing with software frameworks and APIs, each framework works naturally with the programmer at least interacting with (in others mastering) certain technologies or programming languages. This comes naturally if the framework is an extension for another technology.

For example, consider Node.js, a JavaScript runtime. When using Node.js, being a JavaScript runtime, the code will naturally be programmed in JavaScript language. Therefore, working with Node.js framework implies the programmer knows, or can at least interact with, JavaScript language. We’ll call these framework dependency implications.

Following are some implications for some mobile application frameworks.

Mobile Application TechnologyImplications
Native Android Mobile App• Java
Native iOS Mobile App• Objective-C or Swift programming language
Xamarin• .Net (C# programming language) • Extensible Application Markup Language (XAML)
Appcelerator• JavaScript • Titanium SDK
Phonegap• Hypertext Markup Language (HTML) • JavaScript Language • Cascading Style Sheets (CSS) Language
Ionic• Hypertext Markup Language (HTML) • JavaScript Language • Cascading Style Sheets (CSS) Language • AngularJS
React Native• Hypertext Markup Language (HTML) • JavaScript Language (ES6 Syntax) • JavaScript XML (JSX) • Document Object Model (DOM)
Sencha Touch• Hypertext Markup Language (HTML) • JavaScript Language • Cascading Style Sheets (CSS) Language • Sencha SDK • MVC Architecture

There is another cost that is not visible at first glance.  Even though the different platform projects have the same core and logic, ultimately they are individual projects. Each project has a different language and application lifecycle and SDKs, so each project will also need its specialized maintenance. This can all add up.  If creating the application natively appears to be too expensive or the development team does not handle all the implications, another strategy can be used.

Using a cross-platform technology has become very popular as a hybrid solution for mobile development, so you can write one set of code that can be used on multiple platforms and can give the user a native experience. There are many cross-platform mobile app technologies, each with it’s own implications. The strategy is to pick technology that has an implication that the development team masters, plus another consideration. Since this is cross-platform, it is important to choose a solution that has a large percentage of transcribing code; the code that can be written once and run natively across the platforms.


xamarin developerMy Experience

When I decided I wanted to develop mobile apps, my first thought was “What native technologies do I know?”

I had used Objective-C for an iOS application.  If I wanted to make a native android or windows phone application, I’d have to learn about project structure and app lifecycle and hope I could program in the language they used. Since I only knew one native technology (iOS) I decided it was better to invest time learning a cross platform technology.

I then thought “Now if I’m going to use a cross platform technology, what implications can I handle the best?”.  Xamarin was a natural choice for me, thanks to the language and application structure.  C# is one of the languages I handle the best, plus the structure was intuitive. An .xml page with its back end code, the application lifecycle was also C-like. I managed to learn XAML and the app structure and lifecycle quickly.

Later, I discovered that Xamarin generated native apps that shared 95% of the common code. I also got to an acceptable level of understanding in android and iOS native applications. Then I decided to test Xamarin’s generated native projects. It seemed that the native applications were greatly structured and coded. I thought “Wow. In theory, it is possible for someone to develop a full native Android app without knowing Java or the android app structure or even having the Android Studio”. Another plus for cross-platform technologies comes from the abstraction layer.  When using Xamarin, the code handles mobile events (like Swipe) in Xamarin’s way.

I can code once and use these events without even knowing how to do it the native way.

I decided it was a good idea to take full advantage of these generated projects and tried making everything in Xamarin, because some things are not implemented on the framework. For example, Xamarin has no radio button tag for iOS applications. Instead of modifying the generated iOS application and using Apple’s radio button, I decided to implement my own radio button in Xamarin, which rendered natively in iOS. This seemed like a good choice that would become an advantage, but I also found a disadvantage, when making a minimum change on a Xamarin project, it must be recompiled to see the changes on the device. This can be time consuming if one wants to test various changes.


Conclusions

I decided to use Xamarin to build mobile apps because it was cross-platform. So most code would only have to be written once. And the projects generated by Xamarin were native. This is not the case on every cross-platform technology. The fact that the final projects are native is an advantage since mobile characteristics can be used.

Still, I studied native projects for Android and iOS to be able to modify the generated projects if something can’t really be done on Xamarin (I realized Xamarin does not support everything for every platform). Again, this can be done because Xamarin generates native projects.

In other words, I take advantage of Xamarin to reutilize code and generate fully native platforms to the extent it permits me, but I also know how to do it without Xamarin in case I really need to modify a native project. Xamarin’s implications are my strengths in programming. This is how I determined Xamarin was the best option for me when it comes to developing mobile applications.

It is important to note that the best option is a balance between the technical strengths of the development team and the implications of the technology. Xamarin with native platforms background was the best option for me, but I have a C# background.  Another developer could have worked faster with Ionic if, say, the developer is a master in AngularJS.