Browsing Category

Avoiding problems

Avoiding problems, Practical examples

4 Minimum artifacts for an IT cascade-agile project conduction

June 2, 2019

Whenever we are running an IT project, if we already have a deadline set before the start, no matter what, this project will turn into more a cascade than an agile conduction. Besides this status report, I’m listing the minimum artifacts to have a successful project being delivered.

The scope

The scope is basic. It is the base for everything to come. You will extract everything from the scope: the schedule itself, the pace you have to go to keep the schedule, and the team to reach everything. The key information that must be in scope are:

  • The requirement list;
  • The details of each requirement;
  • For who is that requirement applicable?
  • Who has validated the details?

Optional:

  • The time estimates to reach that deliverable;
  • Who is needed to perform the technical part (strong dependencies only);

You don’t have to hold the fanciest document. You just have to hold a document that everybody involved can understand. I’m suggesting this document model.

The schedule

As soon as you have the scope, you will be able to start taking operational decisions. What are the restrictions you have for your schedule? What team is enough for you to reach the given deadline? Can you beat it earlier than planned? Always plan to finish the project before your schedule says, and keep some margin for the problems to come.

The key information that must be in your schedule is:

  • When will you deliver each requirement;

That’s enough. I strongly disagree with going anywhere beyond this point. Otherwise, the project manager will dive to an endless cycle of micro controlling everything. Issues will come with simple or complex documents. Go ahead and create your own model. List the requirement and the date to be delivered;

The status reports

The status report is a weapon and should be used wisely. It can be used to mark milestones for the project and also to create a sense of urgency for some scenarios. It is a powerful weapon. Do not avoid using it. Here you can find the model I’ve been evolving for years. Some of the key inputs:

  • What changed from last status report to this new one?
  • Who are the responsible people for taking decisions on this project? At least one on the delivery team and other on the client (internal or external) team;
  • Where are we in the schedule? Do use percentage here.
  • Major executive items (green/yellow/red) like scope, people and schedule;

Still in the status report. Always remember: if people are asking you for a status report, it means a huge problem. Not sending or wanting it, but the act of asking for it. If they ask for an email to get to know how the project is going on, it automatically means they are not involved as should be on the project. If the status report is green, everybody knows it. Or if the status report will have bad news, everybody must already be feeling the bad news.

The scope changes

Since you are running a cascade project, be prepared for scope changes. I haven’t seen a single project where they didn’t happen. When I hear a scope change, I know I’m walking the wrong way. But it makes me happy because I’ll have the opportunity to put things back on track before the end of the project. Keep track of all scope change requests coming from all the team involved. Make it very clear those already approved and those which won’t be pursued for any given reason. A scope change track document will have the following information:

  • The new requirement OR requirement changed;
  • The description of what’s changed;
  • What’s its impact over the schedule;
  • Is it included in the project or not?

You can use this model to track the changes. Once they are approved, they must be listed as a new requirement in your original scope document.

Others

Few other activities will require you to have a kind of formalization. Using email for that is enough. Some of them will be:

  • Deliveries approval;
  • Changes approval on scope and schedule;
Avoiding problems, Entrepeneurship

Matching Lean mindset with good intention mindset for entrepeneurs

April 17, 2018

The discipline to apply the Lean mindset must be everywhere. Last saturday I got myself into a class where we were discussing project management tools and concerns, focusing on risks.

The Lean scenario

We had this construction project as example. Almost everybody was stating that the project could be consider successful if we deliver it inside the defined scope, schedule, cost and quality planned (as PMI states for years). It is very subjective, because it will lay on the understanding of success each one has. If your goal is just to make a check on your checklist, keep that above. But let’s explore an exception.

Consider yourself as the project manager. The point here is: if during this construction a plumb is broken and your project release toxic wastes in a nearby river? It would cause an environmental damage at least. Naturally fixing the plumb turns inside your project scope. But it’s not the same for all of the rest. It’s not your responsibility to create a workaround to fix the damages to the environment (seeding trees, cleaning the river, etc), neither to care about your company’s image regarding media and the society (marketing advertising, taking water to the affected communities, etc).

To explore that we started discussing if you, as a project manager should tell your organization’s owners about what happened and the subject got into the MCSW tool to help evaluating.

MCSW tool

Making a break, we argued about the MSCW tool when we were defining the risks also. It is a tool to classify the importance of the item you are handling. M stands for MUST, S stands for SHOULD, C stands for COULD and W for would. Clearly there’s not a Lean mindset applied to this tool. It should be just DO, and DON’T. It’s yes or no. You must or must not do something about a requirement, or a risk, or a situation. Discussing about the points in the middle will be waste of time.

The good will thought

Getting back to the plumb. It SHOULD be your concern, as a good project manager to tell, and I suggest, to help planning something to fix the environmental problem and your company’s brand’s image. The project management bible tells you shouldn’t get involved unless it turns your project scope. And here we have a difference between entrepeneurs and people who just work.

But for many times, the complete support to the organization needs may conflict with the Lean mindset. In this case, telling the problem to people is Lean. But getting involved in the resolution is not, unless it is added to your scope. This is the time when the entrepeneur has to have maturity to let the problem be treated by other people and get distance to focus in its real challenges. Otherwise getting involved in unplanned activities, will be faced as micro managing.

Keeping knowledge and good intention close to you

One important thing to explore after this fact occurs is the learned lessons here. Forget about creating a document, writing many pages of FCA (fact, cause, action) analysis, and throwing it to the repository. The most important thing is to make sure the right people understood what happened and what it caused. Because of that plumb broken, our stocks dropped 20% in six months, and that affect the employees there in the edge because we will loose many projects for our competitors due to uncertainty about our service quality. It may cause people leaving the company and knowledge being lost.

The most important thing after this things happen is to keep this kwowledge. For sure you, as the project manager, won’t ever again be discplicent about the soil analysis and researches because you will be concerned with environmental impacts. It’s a chain and everything is connected. From the very beginning, the environmental problem, to the labor force working there.

Avoiding problems, IT is business, Practical examples

5 big companies mistakes moving to cloud without a good plan

February 21, 2018

A lot was discussed, and still have been, about cloud journey. The worldwide big companies already have their strategy turned to cloud ever since the applications start being planned. Potentials of security, scalability, autonomy and many other related subjects are not approached on time of project discussion anymore. The cloud doesn’t generate doubts or lack of trust anymore. Once going to cloud is an old subject, beside the attention points already brought, I discuss here some errors I’ve already seen, as a way to support and contribute to new moves:

 

Face cloud as a side-need

The cloud is the main actor on applications. It’s very common to see companies starting their journey with simple backup or storage routines on cloud. This way they can start dismissing their own datacenters. It’s an important step, many times needed to show safety to a skeptical to changes board. But rollback, backup, disaster recovery, and many other routines, which used to be hard to implement to OPS teams, are now trivial to big cloud players. Using cloud having only this objective is to underestimate cloud’s potential.

Self-managed services have a very high level of automation on the points shown above. Get the benefits from processes automation, and don’t waste time and money researching, planning and implementing. The not self-managed services also have a lot of automation built-in. Backup, rollback and DR are now the basics.

 

Decision matrix negligence

The option for one or another cloud provider is something very important and for many times underestimated. Selecting a cloud provider is like a marriage and can bring troubled relations! I’ve seen companies trying to run away from its 10 or 20 years traumatic contracts with giants like Oracle or IBM, neglecting cloud decision matrix. They ended up signing new contracts leading to new 10 or 20 years contracts with provider X or Y.

Big players like Google, SAP, IBM and SAP allow a very high level of customization. Keep it in your mind during the decision. Those will allow to configure everything needed to a big application. They cover dependencies, integrations and relationships with other systems, specific engineering practices and etc. It’s also very common that complex applications can aggregate benefits from multi-cloud operations. As an instance: infrastructures that has lower prices on provider X can get benefits from FaaS Bigdata services from provider Y, which is faster treating large data volumes. This way one single application can be distributed over more than one cloud provider and also over more than one geographic region. It allows business objectives like cost saving, delay reduction and access to specific features from niche players.

Beside the big players, there are many niche providers of PaaS and FaaS. Digital Ocean, Heroku, Umbler and Elastichosts as instances, are useful for not so robust applications. Those platforms have high abstraction levels, and it cuts the development/operations team learning path.

 

Low knowledge of the potential of the chosen cloud

The savings that can be reached using cloud resources, like rollback, DR, backup (mentioned above), monitoring, alerts and automated actions, are very high. Consider it when executing your migration project!

Evaluate PaaS services to run applications or FaaS for network tasks, Machine Learning, deploy, tests and other. As an example, I’ve seen that every company that had software running over on premise infrastructure, ended up at sometime developing something to improve its deploy and testing tasks. It means that, if 10 companies developed similar software, costing 500h each, they would have spent 5000h creating almost equal software. Having services like CodeDeploy, Device Farm, Fastlane and Firebase, this kind of development is not needed anymore. Fast access to these services saves many development hours. It gives more speed to companies and it means they will be able to answer faster to their customer needs.

 

Low tracking on investment

Do not treat cloud budget as a black box. Track the investment via capable people and separate it by application/business/whatever making sense on that reality. This way true decisions will be taken, contracting or refusing some evaluated service. This is one more practice to prevent the “marriage” with a cloud provider get similar to those contracts of many years with Oracle, IBM and etc, which all big company try to run away nowadays. We have already made mistakes in the past. Let’s learn with them!

 

No updates

As an example, it’s still common for companies to invest amounts of money buying different mobile devices to test apps. Lack of knowledge about services that allow to automatize testing on those devices make that money to keep being wasted and the benefits of automation not reaching the development process.

With more and more niche competitors growing, the lack of updates to the responsible team can be a big problem. Not knowing good alternatives to current services forbids you to discover and use new benefits.

Avoiding problems, Customers, Office, Practical examples

How to avoid suicide applications

January 29, 2018

Having the experience of managing many projects in many different methodologies and different mixes of them, recently I could notice some attributes that happen in all of them to make it to be a suicide project to manage. By suicide I mean a project that will face issues and go down until it reach an unacceptable status, leading to a client loss, or something extreme like that.

The items below were identified as something common to all of managing styles, and if any of them is common to you or part of your routine, it’s time to change something. Some of them regard people relationship and some of them technical parts.

 

No QA environment

A project which has only a formal Production environment. The development is made by coders on their own machines. There is no QA (Quality Assurance) environment.

It looks crazy, right? But it still happens. Usually it happens when who is paying the bill doesn’t understand how catastrophic not having a Quality Assurance / Testing / Homologation can be. When it happens you are dealing with your luck day-by-day like the image above.

The QA environment must be, ideally, an exact copy of the production environment. Routines of copy from PRD (production) to QA must be maintained from time to time. When it happens, whenever a problem on PRD comes, it will be faster to track and simulate on QA. If it’s faster to simulate, it’s faster to find a solution and fix PRD. When production is fixed fast, the client loses less money related to that failure, or its brand is less affected due to that stop.

There can be different ways or minimum-requirements to at least have a trustworthy test before sending new code to PRD. The QA data can be different of PRD current. The environments may have different hardware configurations and etc. But the more differences QA and PRD have, the more time will be spent to track down issues.

Talking about a different service, when you don’t have a QA environment, holding proportions, it’s the same thing as a doctor trying a new surgery method without testing it on mice or monkeys before. It can work. But there is a huge chance of going wrong. And when it works, its nothing but luck.

 

Zero Automation

The more automation you have, the less human errors will happen. People will fail. And it’s normal! Let’s let people to think on what really matters and not on routine tasks. Somehow it will happen in someday:

  • They will commit the last code to the wrong branch. Then production will have a break;
  • They will forget to run a script before deploying a package. Then production will have a break;
  • They will forget to run minimum tests before running a new process or service. Then production will have a break;

A good way to prevent those errors to occur is to automatize as many things as you can.

A good starting point may be automatizing the deployment activity. Many companies I’ve already seen still have issues with deploy. They plan 4 weeks in advance for a deploy. The deploy is done. It crashes. It requires one or two weeks to fix the code and get production running back again. Then it plans with 2 months in advance. It crashes again. If the deploy is a problem, why not turning it into something trivial? Try to make it everyday. A lot of things will be learned.

Automatizing tests is also a great initiative. Automatized tests is one of the best weapons for software stability. The more coverage of tests your app has, the more stable it will be. These two suggestions will require time to be implemented, but their benefits will be felt on software credibility trough the whole company.

Talking about a different service, not having automation is like loading a warehouse box by box, without a fork-lift. A lot of time will be wasted of course. Also some of them will be dropped. Some of them will be shaken too much. It will work, but a lot of risks are added to the project without a need.

 

Key-user displicence

The one responsible for testing your project is the main actor of your routine. They will be whose opinion will be asked about on going practices. This person must be committed and addicted to your project, helping and pointing fingers to anything that goes wrong. The best projects I’ve ever been enrolled had very picky people testing and giving their OK to delivered features.

If your project lacks this concern, many problems may come up:

  • Lack of perception of value. What you have been practicing/telling is not what the customer likes to hear/watch;
  • Lack of alignment of what is developed versus what really adds value to the business;
  • The worst one: Lack of knowledge about the system. This person should be the one who knows all the system. If they don’t, many problems may come up because of different conceptions of why something was developed in some way;

This example is like a mom who doesn’t care about its baby education. It will grow, of course. But it can turn into a time bomb.

 

Low judgement at technologies choices

Technology is something serious and can’t be treated as a fashion trend. Fashion trends come and go and are renewed from time to time. A programming language, framework, feature, cloud provider neither anything related to development can be elected because its fancy or is the thing who everybody is talking about right now. All of this decisions must be questioned by the development team and, if possible, count on help from someone outside the project to think together with the team and reach the best choice.

When wrong technology choices are made, it may cause some problems like the following:

  • Difficulties to find people who know that technology to work with you in your project;
  • Problems in the future due to incompatibility of that technology with the project requirements;

Using the parallel to other services, using a new technology which is not proved yet is like buying a hamburguer with vegan-bacon inside it. It can be good, but is not proved yet. It will be your bet.

 

Deficient communication/status

How is structured your routine of communication with your client? Do you have formal moments to share information? Or do you make it when a trigger come? At this point there is no right answer, like suggested on the article “The magical answer for software development project management“.

But you will have a process to share information and to tell what you are doing to whoever is paying you. It can sound strange, but sharing this information may be a serious problem in many projects. You must ensure the activities you are conducting make sense to the client, and they understand that what you are doing is good to the business. Will you have a weekly meeting? A daily? A status report?

When you don’t have a process to give feedback on what you are doing, is like investing money with an investment company that doesn’t inform you about your gains.

 

Why to attack all of this?

All of the statements above refer to practices that must be figured in your project. Otherwise they will mean problems on the relationship or on the app data. Whenever any of them happen, they mean losing money or at least weakening the system owner’s brand. It may be natural that the main apps of a bank won’t have large issues. But the user doesn’t like when the registration to that cashback program crashes. It means the bank is not serious about their user and marketing advertising.

Avoiding problems, Practical examples

When and how to do a status report

January 15, 2018

Following a list of few articles already written here, one of the activities I consider very important and I enjoy the most is creating the “status report” for the things that depend on me. (This practical example, was created few weeks ago to a real project).

 

Status report are NOT only for projects!

Status report is a bigger thing, and doing status reports is not only for projects, but also for everything that depends on you. Few examples:

  • Telling your leader what, about that key activity to the company, advanced during the last week;
  • Telling people what you learned during that important event;
  • Letting people know how is your project going on (sure);
  • Managing your own team;
  • Let yourself know how your life plans are going on. It can be your tool for the self-retrospective moment;

Whether you want to send it to someone (like your leader eg), or not, the status report is a moment, where you have to stop everything and take a look at what really matters from above.

 

Creating your model

What do you want to report? As of many status reports I’ve already dealt with, probably the most basic information is: date (when it was generated), last updates (textual relevant things) and KPIs (executive numbers). You must also have in mind who will receive it (if your plan is to send it somehow). What is the language the people on the other side will understand? Should it be more executive? Can it be very detailed (probably not)? Below I’m showing some suggestions for some kind of reports as examples above:

 

Key activity status report

You can think on sending your information inside an email’s body, according to how small and/or important is your information. It depends on how formal you want to be.

  • Date – is the information inside an email? The email sent date can be your information. Otherwise, say when the snapshot was taken;
  • What is the activity? Whenever you look at it, it will help you to keep the focus on what really matters and to take away anything which is not aligned with your main goal. What’s the expected result?
  • Dependencies – suppliers dependencies and schedule are very important to show. Anything you depend on must be shown here, because it may affect your progress.
  • Updates – general relevant information. Example: during this week, activities X and Y were finished. The last one, Z, will be finished in two weeks. Also, the scope or important facts regarding an important activity changed.
  • News! – are you researching a new technology to the company? A good section could be news regarding that research, having its content coming from the top influencers.
  • KPIs – how can you measure how close you are to reach the activity’s goal?

 

Event results status report

So the company is investing sending you to an important event in your area. It makes sense to let everyone know what you learned there and sharing the new information with whoever wants it. Imagine it will be 4 days of event, then one compilation a day can be nice.

  • Date – what is the day inside the event?
  • What was the main subjects? What was the subjects you heard during the speeches? Did you know any new important technology? Who was there talking? Was this guy someone known widely? What is his LinkedIn profile?
  • Descriptions about everything – Be short but also say everything relevant that was spoke. How can you and your company get benefits from that speech? Can you suggest an strategy to move towards that opinion/techonology?
  • Opinions! Since you were there, give your opinion. The speech was nice but you have your doubts about the subject potential? Say it!

 

A regular project status report

 

Team progress status report

If you are a team leader, a status report can be very useful to have regular looks at your work as a leader. Let’s look how your team is doing! It will, for many times, get crossed by the regular project status report (above), but there are more things to look when we talk about team, not only projects.

  • Date – the date when was this snapshot taken;
  • Operation / regular activities – it’s basic. How are your regular activities going on? Create a quick KPI here: is everything ok or not? Are you up to the schedule with your regular deliveries? Extract it from the project’s status report suggested above;
  • Customer – how is your relationship with the customer? Do you know who is responsible for taking important decision inside it? Who are your key actors that you must monitore everything they say? What is their straight current opinion about your relationship right now? A satisfaction survey, conducted by someone new can, be very useful;
  • Team health – is everyone inside your team well satisfied with their job? How does it fits in their careers? It’s your job to ensure everybody is well motivated and feeling guts.
  • New stuff – how are your plans to improve? Why not showing plans for a new process you may be thinking to increase people’s knowledge? Also trying to reach someone new inside the customer you don’t have a established relationship yet? It’s time to look to whatever is important over all your responsibility and plan actions to improve them;

 

Next steps

 

When you must let people know about your status report, it’s meant to be presented, not just sent. The most important thing after a big status report, is getting feedback. The feedback will also come from yourself when you are updating your file, and not only from people who will receive it. So, whenever you find something not going well as planned, plan and take actions to put that thing back on track.

Avoiding problems, Career, Customers, Practical examples

Communication issues? Maybe it’s engagement issues

December 24, 2017

I started thinking on this article as my self year’s end retrospective. And I realized the biggest thing I learned during this year regards engagement.

I’ve been hearing, for years, that “80% of the projects that fail, fail because of poor communication”. That’s a sad true, but this year I realized this is an easy but messy abstraction. When you say that communication is the problem, you are hiding many serious problems, not only in your project, but also in your organization. And after that eureka moment, a new one came: people do “communicate the proper way” if they are engaged and have support to develop themselves.

 

Some examples
  1. We have a contract to watch an online app. It’s not very critical, but we still have SLAs to accomplish when it’s down. Then one issue comes and the person from OPS forgets to tell the customer, during the first 15 minutes, that he’s looking for a solution. Beyond that, he takes one more hour to solve the problem, than the 4h regularly expected. It will cause an argument during a meeting between the managers and everybody will finish the subject saying that they had a communication issue;
  2. We evolve a very critical solution, that deals with money, to a customer. Then the developer didn’t create the automatized test and the app breaks when goes to production. It will cause an argument during a meeting between the managers, and everybody will agree that the QA guy didn’t communicate properly to the DEV guy about the missing test.
  3. The project manager tells the project is delayed, but doesn’t tell how much it is. When something goes bad and someone ask for it, he defends himself saying he told about the delay, and had an interpretation issue because those who read didn’t understand the message he wanted to say. Then after that meeting, everybody will agree that he haven’t communicated the right way;

 

Why these things happen

What I learned during this year, regarding engagement, was to identify why these examples happened:

  1. The person from OPS team didn’t tell the customer he was working at the first 15 minutes, and forgot to tell he would take one more hour to solve the ticket, because he was not well empowered of its position. He doesn’t understands his position. If he forgets to tell the customer about the down time, the customer won’t be able tell the users. The users will start calling the call center, and it will generate an overhead on the call center team. So at least 10 people will have more work to do, forcing the company to pay for that extra hours, because of one missing news. The person from OPS wouldn’t have forgot to tell anyone needed if he truly understood the scenario.
  2. The second example has nothing to the QA. The responsibility affects the developer. He hadn’t created the test because he doesn’t know that every one hour of that system stopped, makes the customer to loose US$ 10.000,00. Nobody, when old, will want to tell stories to their children like “hey, once I stopped the production environment, and screwed many people’s life”. So the developer was negligent about the test because he is not well empowered of its responsibilities and capabilities.
  3. The project manager will is not to hide information. He gets paid, essentially, to keep people informed. When he waits one or two months to say the project is delayed for 2 months, he doesn’t think the people from project will be needed in a next one, and it will cause a loss on the company. Since people won’t be available, the original project’s budget won’t be enough, and the whole company will spend more money to hire new people to the next one.

So if you are inside any of these examples, think on the other side as your true friend. Would you let, any of these examples to happen, if you knew how deep it would affect them?

 

Solving the wrong way

It’s easy to put all these problems inside one basket and label them as communication issues. Then, our technical minds will think about processes to guarantee that:

  1. The tickets system automatically send and email telling the customer we’re working to solve the issue;
  2. We will create an integration between the task acceptance tool and the code repository to check if all the tasks have at least one test designed;
  3. The project manager will always present the status report having the customer on it’s side, so no information will be missed again;

The suggestions above are not wrong and shouldn’t be faced as something to be avoided. But they must be the last alternative. They are all mending to lack of people engagement.

 

Solving the right way: build together

People tend to be good. When you share the right way their responsibilities and how their activities affect each other, they will feel inside the group and will always try to help everybody. So why not asking each one of the actors of these examples how they would solve the problem? Present the problem, tell everything that happened because of their behavior. How to solve? This is the most difficult part. Probably the first thing coming from them won’t be the perfect solution or the solution you thought. Then it’s time for to show a better solution and check if it makes sense to those who will put it in practice. A mix of the ideias can be a good start.

And now we talk about people’s maturity to solve problems:

  • If they are junior people with good potential, just letting them to know their responsibilities can solve the problem. They have good intentions! They won’t forget to tell anybody the next time about what’s happening;
  • If they are overwhelmed, you will advice about looking for self management tools. And also will help them to focus on what is important and not getting overwhelmed again;
  • If you realize its needed, why not using one of the process solutions described above as the wrong way? Take care because if must make sense to everybody affected. It depends on people maturity to not feel pushed;

 

The main goal is to look for a mindset of empowering and networks, as described on the image below:

 

Always have next steps

Once I was invited to join a retrospective. The goal was to help a team with an external vision so they could improve their processes. The first thing I asked was where the “next steps” of the previous retrospective were. For my surprise they weren’t.

Always keep track of goals and results. It gives you sense of improvement, and if it doesn’t it will be clear to find where new mistakes were made. Have a periodic checkpoint with each one of the scenarios above until it fits a track where the problems don’t happen again.

After that, when you have the whole solution, you will be able to share your good practice to other teams around you:

  • What happened; Why happened; When happened;
  • What did you do to solve it, what were the first trials, and what actually solved it?
  • What did you learn from it? Next steps;
Avoiding problems, Digital transformation, IT is business, Practical examples

What is telemetry, why it’s important and how to start!

December 17, 2017

The application stability has been a more frequent concern for companies specially when we talk about high value applications. Every time a core application stops working, many money is lost or many money stop being made. Because of that, a lot have been said about telemetry for applications more and more often. But what is telemetry for software actually and how to get benefits from this practice?

 

What is telemetry?

Telemetry is the act of measuring something remotely, by distance, and automatically.

Talking about software architecture, the telemetry is already very easy to find. Some simple examples are the Chrome platform, the Windows, OSX, Android, iOS and Sony’s Playstation OS operational systems, and also your mobile and desktop apps, such as Spotify and Microsoft Office. What these softwares do is to operate and gather all data that matters to its work. Then they send this data, naturally just if you allow, to their manufacturers (Google, Microsoft, Apple, etc). The next step, when they are grouped, is to analyze the data and change things if they have to. The core intention is to improve the systems so they can operate in many different environments having its proper behavior.

So the main thing about telemetry is to operate, gather data, analyze, and then improve the system code to reach a better behavior.

 

Why telemetry?

The telemetry can bring a lot of value to the business. Lets explore an example. Imagine you have an app running, which has a non-interactive FAQ screen to your users. Once your users get there, they will stop using your call center service because they have already found what they were looking for. This means money saving to your company. Now imagine that one of the answers (a quick how-to video) of this screen, for some reason, stops being shown (stops working properly). If you don’t have something checking for this screen’s healthy, it will be hard for you to notice, because we don’t have people browsing on systems 24/7. And then you will depend on some user good will to TELL you that the screen stopped working. It will happen sometime, but before that, your call center will start being called more and more. That’s waste of money because of software bad behavior.

The telemetry can be used to check many levels of service operation:

  • Very deep information, like machine’s CPU and memory. Are they green?
  • Do the number of machines up match your historic knowledge about how many were supposed to be up to support 1, 2 or 3 thousand of users at the same time?
  • Are the core webs-services your customers access every time up?
  • Is the final screen the user uses to login up?

Then when a telemetry practice is watching the important things on your application, you will be able to take actions and prevent problems from happening.

 

How to start?

A good telemetry implementation will depend on the size of information you will want to store and to analyze. The more information you have, the more infrastructure and knowledge you will have to have to process it all. It can even mean using bidata tools. But let’s talk about a new simple example, such as a system that receives vehicles security data from a company that sells insurance letters. A good way to start can be as following:

  • Identify why to measure: let’s measure because it is a core service that tells our customers how their loads are being transported over the roads;
  • Be sure of the goals related: the main goal is to keep the entire system running without down time, because every time this application stops, the contract allows the customers not to pay for that down time;
  • Identify what to measure: let’s check if all of our many data inputs are up. Let’s also check if the inputs are sending the same amount of data they are used to;
  • Set a strategy for measuring: let’s reach every end-point of the many data inputs. If they are available means its healthy. If they are not, its red. Then let’s read the amount of data received in the last minute. If it’s around the known number, its healthy;
  • Set an analysis strategy: can we automatize anything? If one of the endpoints is down, is it useful to restart the operational system, container or application server of the load balancer or the micro services? Or will it have to be shown in a dashboard to a human to analyze?
  • Implement ways to gather the data: let’s create the code to gather data and take actions, or to show it;
  • Show it! Now it’s time to show it. Is it useful to create a chart? Let’s show it using colors, so people can easily identify when there is a problem. If we need results fast, a good very first small step MVP could be opening a ticket on the infrastructure team;
  • Analyze: this is the most important time. It’s time to be critical and identify the root reason of the problem. Do not focus on the problem, but why it is happening. Why it is happening? Do we have problems with the parts that send data to us? Is the problem on our side? If yes, is our application running the way it should? Do we have to change something in our development process?
  • Take actions: through code or not, solve the things you found in all the steps above;

 

The telemetry can bring a lot of value to the business. It will give you intelligence to act before things happen. If your business is critical, it can mean a lot of money easily. It’s a common practice to many things in our administrative areas, like the PDCA mindset thought, why not do that for our software?

Avoiding problems, Customers, Office

The magical answer for software development project management

December 3, 2017

Lately I’ve been negotiating with a lot of different clients about many different projects. Having a quick look at the projects, it’s incredible how people wrongly seek for one single project management methodology to rule them all. Beside that, when clients look for “agile methodologies”, what the biggest part of them want to say is: “let’s use Scrum for everything”. Then after my opinion was asked by a friend who was meant to establish a PMO, I had the ideia of this article.

 

Different clients have different needs

In my scenario, as a consulting company, it’s very clear to notice that different clients will have different needs. It’s common to be asked about software development methodologies. The main thing is that, even inside the same company, which is not a consulting as instance, there will be different ways to manage projects. There is not a single pattern. It depends on people. It depends straight on the teams maturity to act, and I will show few examples based on the infographic “Software development maturity evolution brief story“.

The traditional / waterfall / CMMI approach:

Yet the most common on big organizations. It gives executive information to managers and a lot of very concrete information about the project. It focuses a lot on process and files to keep track of everything that is happening on the project. Dependency mapping, communication mapping, scope controlling, and many others will be done by the manager. This will cost a lot of money.

The Scrum approach:

More flexibility, less process, but still some issues. Scrum will allow the project to be more dynamic due to less focus on processes and files. What Scrum says is “keep sending work and we will keep delivering it”. It has many good things: less time spent on bureaucracy, “customer first” mindset, etc. But it shows few problems: it’s hard to work with deadlines and dependencies, and dailies can easily lose the value.

The XP practices:

Flexible, focus on finding value fast, feedback at every corner. XP focuses on finding value as fast as possible with the MVP (Minimum Viable Product) mindset. It also helps to improve the team practices constantly due to it’s cycles of constant feedback. XP needs a very disciplined team to run with, otherwise they can easily loose the focus due to the lack of practices to controlling.

The DevOps approach:

Self-service, no bottlenecks and automation. DevOps has been the most-said IT word for the last year at least, but very few people can actually practice it. It focuses on bringing everybody that matters to the project to work together, and that includes business people, UX people, DEV and OPS people, and everything else that matters. They must have autonomy to take decisions. Nobody can be a bottleneck. The developers must have the self-service mindset, otherwise they will depend on others to finish their jobs. DevOps also bring some challenges, as the DEVs not enjoying to do OPS tasks, and OPS guys not enjoying to code.

 

Different mindsets for project management

All of the models above were explored with the benefits and the problems they bring. Each of them can be useful if applied in the right context. So, no one of them is the magical answer to whatever are the problems you may be facing in your project(s). The perfect scenario is to mix things up, EXPERIMENT, until you find the best model for you and your team. But how to do that? If your moment is not allowing you to find that now, you probably are overwhelmed by the operation and are forgetting to think on your real goals. Try to look things from above. Your main goals, on software development, are shown above, and there’s where your effort must be focused:

  • Deliver value constantly – changing the application background color from blue to red may be nice. But does it really adds value to the business? Will it make the difference to the project or to the final user? Focus on what really matters and not only on creating more code.
  • Customer first – the reason for every software project to exist is the end user. Always aim to please that team. If their opinion is not green about what you are delivering, they won’t use it. And your project will be useless. Is your end-user happy? Do they feel like the software has good user experience? Do they find value on using your tool?
  • Experimentation – the fastest way to improve things, even when you don’t know what to improve. Experimenting after a good retrospective is something to do very often.
  • Focus on people – the key to reach all the dots above. If people are happy and find value on your organization, trust you and like their environment and routines, they will be very likely to do and test everything the team may bring up.

 

Then manage your own way

So the answer for you to apply the best development practices to your projects is your mindset. Once your mindset is aligned with the goals you must reach, forgetting all process addictions, then your right process will be created naturally by the team.