Jai's Blog

Referred Link - https://www.linkedin.com/pulse/how-manage-app-developers-non-technical-founder-rahul-varshneya

Seek Assistance While Hiring

If there’s one thing that should get your maximum focus, make that hiring the right people – whether it is in-house or outsourced developers.

Bad developers make bad software. And that’s the end of your mobile app business. And most entrepreneurs blame their tech team on the poor quality of the product. But, if they hired the right developers in the first place, those non-technical founders could invest their time in marketing or sales.

Whether you’re hiring an in-house team or outsourced, seek assistance. It’s tougher to hire a developer to join you if you don’t speak their language – you gain no respect and you can’t tell their level of skills.

Look into your network and get introduced to a senior technical person who could help you choose the right developers once you’ve shortlisted.

If hiring an outsourced team, whet them by their portfolio – download their recent most apps and check for design, user experience and whether the apps function well without lags or bugs. Then, ask for their three most recent customer references.

If the outsourced team engages in a meaningful discussion about your app idea and its category and offer suggestions to make it better, they’re more likely to help you build a better app.

Your App Is Only As Good As The Brief

If you expect your developers to deliver a fantastic app, you’ve got to give them an equally good brief.

Detailing of your app idea via mockups or preparing a detailed requirements brief not only helps your developers understand your expectations well, but it also helps to bring clarity to your own thoughts.

Give as detailed a brief as you can illustrate, as you don’t want your developers to draw any assumptions while developing your mobile app. Take that extra time creating a workflow, mockups or wireframes with description of your app idea before you engage with a developer.

Before the actual development begins, insist your developer creates a detailed functional specifications document to go further in depth into every workflow and functionality of your app.

You can download a sample with few pages of a functional specifications document we create at Arkenea. This will give you an idea of the level of detailing you must have for your app before the development begins.

Learn About Technology, Don’t Learn To Code

A lot of non-technical founders make the mistake of learning to code. While it certainly does no harm, and can only benefit in understanding technology better, but it does no good in the process of building a mobile app.

The reason is that the developers that would be creating your app have several years in learning to code plus several years of experience in real world building applications that have live users.

Spend some time learning about the different technology stacks at the backend, database options, web services, hosting solutions (AWS, etc) and front-end technologies rather than learning to code. You will be better informed, make better technology choices and can engage effectively with your developers.

Don’t overcompensate for lack of technical knowhow

Developers don’t like someone shadowing them and micro-managing during the development phase, especially when it comes from someone that doesn’t understand coding.

Non-technical founders tend to overcompensate their lack of technical knowhow by micro-managing development projects. Don’t be that person – as a founder of the business, there are many other areas that require your expertise and attention.

For instance, you need to prepare a marketing strategy and implementation plan for pre-launch, launch and post-launch of your app. You need to start building an audience, whether it is an email list or via Facebook group. You could be starting to build partnerships while the development is ongoing.

Keep a keen eye on the progress of the app development and play an active role in evaluating the build at each stage, continue to provide feedback and test for quality. But, don’t expect a code push and build to check every day or each week during the development process.

Development takes time and oftentimes, there isn’t much to showcase as progress that you can evaluate in terms of a build on the phone.

As a non-technical founder of several technology businesses, my advice to you is not to feel challenged because you don’t have technical knowledge or skill sets. There are many aspects of running a technology business that are equally or more valuable. Focus on those skills that you have which can make your business stand out and let developers do their job.

Referred Link
http://www.girlsguidetopm.com/2017/01/5-mistakes-every-project-manager-should-avoid/

To err is human. But if you’re a project manager, erring isn’t really something you can afford to do.

Even a tiny mistake on your end could cost the organisation a lot of money, or worse still, the entire project. And if things go really bad, all your colleagues will end up losing faith in your ability to get work done.

However, you can save yourself from the perils of making serious mistakes while managing your projects. Here’s a list of common pitfalls facing project managers, and how you can avoid them tripping you up.

1. Forgetting The Team

When you launch a project, it’s imperative to identify all the stakeholders, and make sure they’re all on board with your plans.

This includes everyone who invests time and energy into the project, and is directly affected by it. If you fail to understand that every single member of your team is important, you could end up undermining, or even causing the complete failure, of your project.

Tip: Check out this article on how to engage stakeholders because your team members are stakeholders too!

2. Lack Of Communication

Would you like to see your project systematically self-destruct? All you have to do is stop talking.

If you don’t set up elementary communication channels and guidelines into place right at the beginning of the project, you can forget about results or completion. Make sure you do regular status checks, target reviews, and team temperature checks; this will keep you and the team engaged and motivated at every stage of the project.

Tip: Build out a communications plan at the beginning of your project. Don’t know where to start? Here’s a free project comms plan template.

3. Being A Robot

Yes, numbers are important, deadlines are important, and clients are important. But if that’s all you care about, you might as well just replace your heart with a battery pack.

You’re working with people, not machines; everyone has feelings, and everyone gets stressed out. Try and understand that if you act like a walking talking spreadsheet, these people aren’t really going to care about your problems (in this case, your project) either.

Tip: Your business case is important, and deadlines matter, but people are people too! Think about how you lead teams so that you show empathy, consideration and respect in your interactions.

4. Prioritising Budget Over Quality

In order to finish the project and stay within the budget, some managers make the mistake of focusing only on getting deliverables out of the way.

In the process, all quality checks are bypassed; what goes out is an end product with lower quality standards than the average fast food joint.

Tip: Plan for quality. Set your quality standards at the beginning of the project and make sure these are both communicated to the team and agreed by the end users. Then check you are on track to achieve them every so often during the project so there are no surprises. [Note from Elizabeth: Here’s my take on why quality plans aren’t all they are cut out to be.]

5. Failing To Understand Effort

Now that we’ve made it clear that deliverables aren’t just ‘things that need to be pushed out of the door’, let’s talk about something more important. Meeting deadlines and quality standards takes time and energy.

If you’re unable to ensure quality, or if you’re unable to meet deadlines because of the high quality requirements, you should be able to explain to your client why this is happening. Don’t come charging into office and start admonishing your workers about how the client is harassing you for something.

This just shows that you have no idea what your team’s capabilities are, and that you couldn’t care less about them either. Not the greatest idea, that.

Tip: Projects take effort. Involve your team in creating the estimates so that you have a better idea of what is involved. Keep the communication going in both directions so you know what they are able to deliver – and you don’t overpromise to your client.

These are just some of the few mistakes you should be wary of making when you embark on a new project and a few things you can do to stop them causing you headaches.

Just keep in mind that sometimes, whatever can go wrong will go wrong. Don’t get bogged down if a project doesn’t go as expected—use it as a learning experience, and don’t repeat the same mistakes in the next one.

Referred Link
http://www.knowledgehut.com/blog/featured-category/achieving-leadership-excellence-inspiring-great-teams

Great leaders are just ordinary people who have certain traits that set them apart — and enable them to achieve the extraordinary. Despite differences that stem from culture, gender or age, all leaders who have been a true inspiration to their teams share similar patterns of behaviour.

They lead the way. Leaders establish their minimum benchmarks of excellence, and then set out to show others how to go about achieving them. They lay out principles for others to follow, and targets that they should achieve.

They inspire and motivate. Inspirational leaders are passionate about envisioning the future, and enthuse the team to share their vision of what the organization can become. They create exciting possibilities that everyone can achieve together, working as a team.

They innovate and challenge processes. Great leaders question existing processes, and look for ways to do the same thing in a better way. They are willing to experiment, are not afraid of risks, and take failures as learning opportunities.

Leaders delegate with care. A good leader knows the strengths and weaknesses of each of his team members. By delegating tasks appropriately, and trusting the team with his ideas, he can free up his time to work on higher level tasks.

They appreciate the efforts of others. Recognition works wonders, and by acknowledging individual contributions and celebrating accomplishments, leaders make their people work twice as hard! Genuine appreciation kindles determination, and instigates teams to work with sincerity.

They build trust and foster team collaboration. Teams that work well together achieve extraordinary success. Leaders foster team trust and strengthen teams, helping each member to work with transparency and accountability.

Above all, great leaders are honest. Honesty and sincerity should be the bedrock of any successful business. By setting themselves up as an example, leaders can influence the workspace to reflect ethical behaviour as a core value.

Referred Link -
https://www.mountaingoatsoftware.com/blog/a-simple-way-to-run-a-sprint-retrospective

There are perhaps as many ways to run a retrospective as there are teams to conduct them. I want to describe my favorite way, especially because it's an approach that has stood the test of time, having worked for years with many, many teams.

The Start, Stop and Continue Retrospective

I like to conduct a sprint retrospective by asking team members what they would start, stop and continue doing. This type of meeting becomes known as a “start, stop and continue” meeting.

The start items are things a team member thinks the team should add to its process. Some examples would be:

Showing the software to customers early
Specifying acceptance tests early and with customers
Doing code inspections
Being on time for daily standups
Finishing one story before starting the next

Items on the stop list are things that someone on the team thinks are inefficient or are wasting time. The team should stop doing these. Examples from past retrospectives include:

Checking in code without being sure all tests will pass
Taking more than 15 minutes for daily scrum meetings
Skipping product backlog refinement meetings when we’re feeling behind at the end of a sprint

The continue list contains items the team would like to continue to emphasize but that are not yet habits. So any of the start or stop items above could go onto the continue list and stay there for a few sprints.

Eventually--once the item became a habit--it would be removed from the continue list. Otherwise, the continue would become tremendously long.

Ask for Items in Different Ways

A ScrumMaster can ask team members for items in different ways. The easiest is just to say, “Yell them out,” and team members are free to intersperse start items with stops and continues. This is my default mode.

But, it can get repetitious sprint after sprint. So, I’ll mix things up and sometimes I’ll go around the room asking each person to give me one item, perhaps making two passes around the room before opening it up for additional items.

Other times, I’ll want to emphasize a specific type of item--often the stops. So I’ll ask all team members to yell out nothing but things to stop doing. Or, I’ll combine approaches and go person-by-person around the room asking each to identify one thing to stop in the team’s current process.

There are plenty of ways to mix up the idea generation in a start-stop-continue retrospective so that it will take a long time before it gets boring or repetitious.

Vote

After enough ideas have been generated, have team members vote for the most important item or items. It’s often obvious when it’s time to do this because the creativity has died down and new ideas are not coming very quickly.

The ScrumMaster can have each team member vote for the one, most important idea or can use any typical multi-voting approach. For example, give each team member three votes to allocate as they wish (including all three votes to the same items).

I like multi-voting in a retrospective. The nature of most retrospective items is that many do not really take time to do it. Many are more behavioral. Consider being on time for daily standups from the examples above. That doesn’t take any time. In fact, perhaps it saves time.

Multi-voting would allow a team to choose to work on that behavior and perhaps another couple of items. Generally, I’d pick no more than three. Even if they don’t take any (or much) time, choosing too many items does detract from the importance of those selected.

In addition to voting for new items to pursue, discuss whether items on the continue list have been achieved, are no longer important or should be otherwise removed from the list.

The Next Retrospective

In the next retrospective, I suggest the ScrumMaster bring the list of ideas generated at the previous retrospective--both the ideas chosen to be worked on and those not. These can help jump-start discussion for the next retrospective.

I tend to write them on a large sheet of paper and tape it to the wall without any fanfare or discussion. The items are just there if the team needs them or wants to refer to them. I then facilitate a new start, stop, continue discussion.

Benefits of Start, Stop and Continue

I find that conducting retrospectives this way is fast, easy, non-threatening and it works. A start, stop and continue meeting is very action-oriented. No time is spent focused on feelings. We don’t ask team members how they felt during a sprint; were they happy or sad, warm or fuzzy.

Each item generated will lead directly to a change in behavior. The team will start doing something, or they will stop doing something, or they will continue doing something until it becomes a habit.

Yes, I’m prepared for many people to leave comments saying it’s important to work through people's’ feelings first. Or that we won’t know how to act until we’ve first dealt with how people feel. Go ahead. In some cases that may be true. But in plenty of other cases, we can identify what to do (“we need to start testing sooner”) directly.

And that’s the strength of a start, stop, continue approach to sprint retrospectives.

What Do You Think?

What do you think? How do you like to run retrospectives? And specifically, is there anything you’d like to start, stop or continue about your own retrospectives?

Referred Link
https://www.mountaingoatsoftware.com/blog/what-are-story-points

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.

What Goes Into a Story Point?

Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include:

The amount of work to do
The complexity of the work
Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors. Let’s see how each impacts the effort estimate given by story points.

The Amount of Work to Do

Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text.

The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page.

The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.

Risk and Uncertainty

The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item.

If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.

If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate.

Complexity

Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them.

Now think about another web page also with 100 fields. But some are date fields with calendar widgets that pop up. Some are formatted text fields like phone numbers or Social Security numbers. Other fields do checksum validations as with credit card numbers.

This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the user enters an American Express card, a four-digit CVV field is shown.

Even though there are still 100 fields on this screen, these fields are harder to implement. They’re more complex. They’ll take more time. There’s more chance the developer makes a mistake and has to back up and correct it.

This additional complexity should be reflected in the estimate provided.

Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity

It may seem impossible to combine three factors into one number and provide that as an estimate. It’s possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item.

Estimators then consider how much effort to include for dealing with the risk and uncertainty inherent in the product backlog item. Usually this is done by considering the risk of a problem occurring and the impact if the risk does occur. So, for example, more will be included in the estimate for a time-consuming risk that is likely to occur than for a minor and unlikely risk.

Estimators also consider the complexity of the work to be done. Work that is complex will require more thinking, may require more trial-and-error experimentation, perhaps more back-and-forth with a customer, may take longer to validate and may need more time to correct mistakes.

All three factors must be combined.

Consider Everything in the Definition of Done

A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.

Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work will be worth it.

Seek Assistance While Hiring

Your App Is Only As Good As The Brief

Learn About Technology, Don’t Learn To Code

Don’t overcompensate for lack of technical knowhow

1. Forgetting The Team

2. Lack Of Communication

3. Being A Robot

4. Prioritising Budget Over Quality

5. Failing To Understand Effort

The Start, Stop and Continue Retrospective

Ask for Items in Different Ways

Vote

The Next Retrospective

Benefits of Start, Stop and Continue

What Do You Think?

What Goes Into a Story Point?

The Amount of Work to Do

Risk and Uncertainty

Complexity

Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity

Consider Everything in the Definition of Done

Total Posts

Search this Site

Connect with Me

Translate Articles

Total Pageviews

Contributors

My Achievements

My Favorite Links

Contact Form

Blog Archive

Recent Posts

Followers

Report Abuse

Popular Posts

Comments

Seek Assistance While Hiring

Your App Is Only As Good As The Brief

Learn About Technology, Don’t Learn To Code

Don’t overcompensate for lack of technical knowhow

1. Forgetting The Team

2. Lack Of Communication

3. Being A Robot

4. Prioritising Budget Over Quality

5. Failing To Understand Effort

The Start, Stop and Continue Retrospective

Ask for Items in Different Ways

Vote

The Next Retrospective

Benefits of Start, Stop and Continue

What Do You Think?

What Goes Into a Story Point?

The Amount of Work to Do

Risk and Uncertainty

Complexity

Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity

Consider Everything in the Definition of Done

Total Posts

Search this Site

Connect with Me

Translate Articles

Total Pageviews

Contributors

My Achievements

My Favorite Links

Subscribe To

Contact Form

Blog Archive

Recent Posts

Followers

Report Abuse

Popular Posts

Comments