Saturday, June 27, 2015

Estimating Projects the traditional way and running them using “Agile” methodology

Estimating project is not easy if you don’t have a right approach. You can be in MS Project land trying to figure out little details, but those details change and then you are stuck maintaining schedules in MS Project.
A lot of companies are trying to change to use “Agile” methodology and I am putting the word Agile in quotes because there is no company out there that is following exactly what you are taught in ScrumMaster courses and SAFe courses. That means that companies sooner or later end up doing what works for them and that could be an approach that belongs somewhere on the line between Waterfall and Agile; for some companies closer to Agile and for companies closer to Waterfall.
For example a lot of companies get a list of projects that need to be estimated, prioritized and approved by a board before projects can be worked on. Then when they are approved, you are asked to provide project schedules with milestones and deadlines with very high-level requirements. Then some of these organizations say “let’s run these projects using agile methodologies”. What does that really mean?
What does that really mean if you have already broken down the project into a list of tasks and you estimated it all?
Can the agile team take these requirements and start assigning points to user stories and deciding how much to handle in a given week? In the meantime based on estimates, you already know how much needs to be handled in order to even have a chance to deliver the project?
Is that really fooling the members of the team believing that they will set the velocity based on how much the team can handle and in the meantime the estimates have been already committed?
Let me explain how I approach this. Let me first step back to the point when the estimates are being provided. What works for for me is reading the requirements document and breaking down the project into a list of features and sub-features. Then if the requirements document is written in such a way that it lists the user stories, you can easily distribute these user stories into the appropriate sub-features. If the requirements document does not explicitly list the user stories, then I would put a product owner hat on and extrapolate the user stories out of the requirements document.
Now that I have all the user stories under each sub-feature, I can do some high-level estimating on each story and the unit for estimation is the number of days. It is not some virtual story points and it is not hours; it is the number of day and you will see why later in this article.
After estimating each user story under each sub-feature, you can add up the estimates and have the list of sub-features and numbers for each sub-feature.
Now that you have the list of sub-features and estimate for each sub-feature, it is all fun after this point. It is fun because I like using Trello website to pre-plan all the sprints and ultimately produce the deadline (production launch date), because that’s what business expects from us. NOTE: I don’t do sprint planning at the user story level; I do this exercise of sprint pre-planning at the sub-feature level in order to produce that deadline and to have a rough idea how each sub-feature needs to be worked on throughout the project.
What are the steps to be taken before playing the drag-and-drop game in Trello?
  • Decide on the duration of the sprint (let’s say 4 weeks)
  • Take the list of sub-features and estimates and break down each sub-feature into multiple sub-feature parts that are each 5 days worth of work. For example, if you have a sub-feature that has the estimate of 20 days, then you would break that sub-feature into Sub-Feature A part 1, Sub-Feature A part 2, Sub-Feature A part 3, and Sub-Feature part 4.
  • Now you are ready plug this all into Trello backlog list and then the game of dragging and dropping starts :)
Here is how it could look like in the backlog list when you start:



Now that you have all the sub-feature parts in the backlog, it is time to gauge what the optimal number of resources is. Let’s do some simple math.
  • 6 resources
  • 4 week sprints (20 working days)
  • if everybody is a robot, then the team should be able to chunk away 120 days (6x20) out of the estimates. Yeah right !!! With all the meetings and interactions between teammates, a reasonable number to achieve in each sprint would be 60–80 days worth of work. If each part of the given sub-feature is equivalent to 5 days worth of work from the estimates, then you should be able to drag and drop 10+ of those parts into a given user sprint.
You as the technical lead and technical project manager know best how each sub-feature is related to each other and you are deciding those things as you are loading each sprint with the list of sub-feature parts.
Here is how it may look after going through this exercise. It looks like the duration of the project would be around 14 weeks (3.5 months). If you know what the start date is, then you can easily calculate the production launch date. You also know when you need to start each sub-feature and when each sub-feature is supposed to be completed. That can help you point out some major milestones to your senior management team.



You are done. Provide your boss the duration of the project, major milestones and the production launch date that you can achieve based on these high-level estimates.
What’s next?
Well, now you need to share this with the team and help out the team do proper sprint planning at the user story level by using this sub-feature plan. I happened to use Trello just for the purposes of “sub-feature” planning, but when it comes to sprint planning at the user-story level, your team will need to use whatever tool your company approved.
Good luck and have fun.

Almir M (almirsCorner.com)
#Agile #AgileMethodology #ProjectManagement #ProjectPlanning #SoftwareEngineering #SoftwareDevelopment #Scrum #Planning #Trello #SAFe 



Thursday, June 18, 2015

Detect errors on time to gauge the success of your launch — Simple concepts, huge benefits!

When you develop your applications, do you put thought into a proper logging mechanism? In a perfect world, there should be no errors in the logs, but we all know that’s not the case in reality. Then how do you know that the project you just launched to a production environment is not introducing new errors or new types of errors on top of already existing errors that your triage team has been investigating?
Maybe on day 1 of your launch, you don’t see customer complaints, but in reality your systems are hurting or bleeding slowly. Yes, a network operations team could be checking the high-level health of the systems through a list of dashboards, but what are we software developers going to do to introduce a new level of detection? This all starts from the enterprise architecture and frameworks you build. Let’s assume you have a very robust logging mechanism and that this mechanism allows you to log the happy path. Let’s also assume that you have very clean guidelines for error and exception handling and utilizing the logging framework where necessary.
Now that you have all of the above in place, at the beginning of your project that is implementing business requirements within the existing framework, you have ability to cleanly define the top 20 cases to measure the success of the new code/features. Each developer can use this top-20 list as a guideline while developing the code and logging happy/negative cases. Let’s say your code is now in production and you are scanning through the logs manually and detecting the top-20 cases. Is this efficient? Are you supposed to do this on daily basis manually?
My recommendation is that you develop a lightweight solution that will be able to automatically do the following for you:
  • * Scan the logs on daily/hourly basis and produce the count of the top-20 scenarios and display the results in a table on some internal dashboard website
  • * Have ability to detect if the number of errors in each category increases by more than X% (daily comparison of errors per Y units of work and units of work could be somehow defined and tied to the traffic on your website).
  • * Have ability to detect if new types of errors and exceptions that start happening so that the team can manually assess the situation and then add each new type of error to the top-20 list and start tracking it on daily basis.
If you have all of this automated, then there is no manual work needed when you launch something to production. You will be able to tell if your new code is hurting the numbers on existing top-20 categories and you will also be able to tell if you started introducing new types of errors that hurt the revenue of your company. Let’s assume that your production deployment involves deploying to a smaller/secondary data center first and then later to the rest of your data centers. Then this type of mechanisms can help you decide whether you continue deploying to the rest of data centers after deploying to that smaller data center.
These are all simple concepts. You can spend minimal efforts in building it yourself or maybe decide to buy a solution. The importang thing is to always take the “keep it simple” approach in decision making.

Conclusion:

Start by tracking top-20 errors on daily/hourly basis and use the percent of change as the gauge for the success of your code being pushed to production environments. Detect the newly introduced low-level engineering errors in production on time to gauge the success of your launch. Don’t over-design this! Keep it simple!
Almir Mustafic (almirsCorner.com)

#softwareengineering   #softwaredevelopment   #code   #coding  #programming   #software   #errors   #ExceptionHandling   #NOC  #monitoring  

Tuesday, June 2, 2015

Study to pass school (aka get credentials) or Study to Learn?

After interviewing a lot of candidates for software development jobs, I am starting to remember the days when I went to school and I am wondering about the following question:

Should students study to pass college or should they study to learn?


This question comes from my concerns that I have about candidates from both great and average universities. There is no direct relation between your skills and your credentials; it is really up to individuals and how they approached studying. When I attended the University of Toronto in mid-90s, I studied Computer/Electrical engineering. This university was considered to be one of the top three universities for computer/electrical engineering program in Canada, and also among the top 10 when compared to big players in US. My parents were willing to pay for me to go to this school even though I had a full scholarship offer with another average university.
Did I make the right choice attending the better school? Are you making right choices now?
Right choices? It all depends on how I approached my studying. If I had studied to only pass and get good credentials from University of Toronto, then my parents’ money was not invested properly. I studied to learn and if that meant that it would actually affect my grade in a negative way, that’s how I approached it. This may not make sense, but we all remember the days from our college when exams had things that you would never apply in real life and in the meantime the courses were also teaching things that were very applicable in real life. If you studied to learn things for long term, then a lot of times you would get in trouble. Don’t misunderstand me here. Yes, there are things that are taught in courses for which you can’t see applications in real life in that given moment, but you need to plow through it and you will see answers to these doubts at the end.
I have also seen the opposite effects. I am talking about schools diving into real life examples too soon without teaching students good fundamentals in that area. If every student approached this, then nobody would be inventing new things; it would just be a game of putting components together. There has to be some golden balance.
Going back to interviews that I mentioned at the beginning of this article. Regardless of your school credentials, you need to have very strong fundamentals and you need to be able to apply those fundamentals at the right time. For example, software engineering is a very wide field these days and it is impossible to have expertise in all the areas. This is where the fundamental knowledge kicks in. When you jump from field to field in software engineering industry, you will not know everything but you will need to apply those fundamentals and learn quickly. That’s where you separate yourself from others.
In conclusion:
Put the credentials of your university aside and use the great things from your school to learn.
Almir (almirsCorner.com)
#school #college #university #study #credentials #tech #softwareengineering #computerscience #programming #coding