entrepreneurship, Experience, hustle, Hustle Estate, Leadership, Learning Lessons, Real Estate, Technology, Tools, Uncategorized, Vision

Hustle Estate – Buying Your First Home – Ep 4

Questions or comments – reach out to us!
Twitter/Instagram – @HustleEstate
HustleEstate1@gmail.com

Looking to buy your first home? We have some practical tips to help you find the home of your dreams. Both of us share our experiences buying our first homes (multifamily and condo). When we started looking, we had some ideas of what we wanted, but after we made our purchases we learned a lot more. Learn from us so you don’t repeat some of our mistakes.

Happy hustling!

Advertisements
Hustle Estate, Leadership, Learning Lessons, Real Estate, Technology, Tools

Hustle Estate – Career Pivoting to Real Estate – Ep3

 

iTunes & Google Play

Learn how Ed made his way into real estate. Ed’s career didn’t begin in real estate. He was curious about owning property at a young age, but started working in non real estate financial institutions after college. Once he bought his first property, he quickly realized he’d rather spend time understanding the real estate industry than other financial businesses.

Feel free to leave us a comment or send us an email at HustleEstate1@gmail.com

Agile, Communication, Estimation, Focus, Goals, Improvement, Leadership, Learning Lessons, Remote, Remote Leadership, Team Building, Tools

Great Teams > Improved Estimation

A few weeks ago, one of the teams I lead tried a different way to structure their two week build.

Instead of committing to work and tasking everything out at the start of the two weeks, we started each day committing & tasking work and ended each day seeing if we made those commitments. Also, we had a retro at the end each day to try and improve for the next day.

We tried this approach due to two identified issues (described in Day 0)

  1. New team members cause storming
    • We added two new team members and we were storming. Our old processes of accomplishing work changed because new team members needed to learn our solutions and that added time to what we thought we could accomplish in the past
  2. Estimating our work is hard and we were struggling with it
    • Due to adding more time to what we thought we could accomplish, we had trouble estimating what we could truly accomplish over a two week period (our build cycle). We found that we were crunched for time or dropping work as we neared code complete.

It’s been over two weeks since we started this process. What happened as a result of this different way of working? Did we improve our estimation due to this?

The short answer is no.

Instead, we accomplished something I believe may be more valuable. Our teamwork improved! Instead of improving our estimation, we improved our ability to accomplish whatever was put in-front of us.

Here is how our teamwork and ability to accomplish our work improved

  • Setting a daily goal made each day clearer
    • We had a really good idea of what we wanted to accomplish by the end of that day and it reduced questions because we could bring them up at the start or end of each day, if not earlier during our teamwork on Zoom (Day 3)
  • Increase in challenging each other created better solutions
    • We started to challenge each other more often, when something didn’t seem clear or there seemed to be a better way (Day 7)
  • Our daily schedules helped understand our real capacity
    • Simple yet effective because it helps us understand how much capacity we had to accomplish work that day (Day 4)
    • We established that we would always use Eastern Time when describing meeting times, so we don’t have to figure out all the different time zones (Day 6)
  • Leveraged Zoom more often to improve problem solving as a remote team
    • We started to improve our problem solving because we used Zoom more by talking about issues that came up and we began raising awareness to roadblocks earlier (Day 3)
    • Pair-programmed via Zoom more often for work that was newer to others, regardless of experience level – this helped everyone learn and improved teamwork (Day 1, Day 2, Day 3)
    • Brought people into our Zoom room, instead of having solo conversations, so everyone could hear the issue and bring solutions to the table (Day 8)
  • Thinking about what the work really required, rather than guessing/assuming
    • We started spending time each morning really thinking and solution the story via tasking to create as many tasks we needed to do to accomplish each story, rather than just creating a few tasks based generalities of what we were trying to accomplish
    • This also led to understanding potential roadblocks sooner, which the team then went and tried to solve immediately, rather than running into the roadblock during development (Day 4)
  • Building time for future work with time boxes to avoid getting in the weeds
    • If we thought we would bring in new work the next day, but we didn’t have familiarity with it, we would build time (30 minutes to an hour) to learn about that work instead of guessing on the time it would take to accomplish the work (Day 3)
  • Celebrate success often!
    • We did an excellent job of finding ways to improve, but we forgot to celebrate our success until later in the two week build. We did so much and it was amazing to see! (Day 7)

So what’s next for the team?

We continue to utilize these ideas in our day-to-day build process. We’ve even added to them. Most notably, we have a weekly goal and use daily goals that roll up to the weekly goal. These goals are based on business deliverables for a project we are currently working on.

Final thought

We set out to improve our estimation. Instead, we became a better team. That result is better than expected. Why? Great teams can accomplish any challenge that is placed in front of them, even if their estimation is off. Our team’s goal remains the same – create amazing software solutions to make the real estate experience faster and easier for everyone. Now the team is better positioned to accomplish that goal because we are one step closer to being a great team.

(Featured Image Credit: https://www.genequityco.com/insights/m-a-success-hire-a-team)
Agile, Estimation, Improvement, Leadership, Remote, SDLC, Technology, Tools

Daily Sprints – Day 9 (the last day!)

The LAST post! I posted for the last two weeks about the previous day to provide interesting insights on how the team is trying to improve their estimation! See Day 0, Day 1, Day 2, Day 3, Day 4, Day 5, Day 6, Day 7 and Day 8!

What have you tried that works or doesn’t work?!

Day 9 – The Last Day

The last two weeks have been amazing. I will spend some time later this week reflecting and writing about the overall process. Last Friday was really our last full development day and we were finally in our Beta environment.

All we needed to do on Beta day was some small testing. So we needed to figure out what we wanted to accomplish.

Our goal for the day:

  • Take some time to learn a new version control that we are moving towards soon
  • Add some more integration tests
  • Get a quick POC for an API call to an outside vendor we haven’t used before but plan on using soon

What did we accomplish:

  • Added integration tests
  • Created a plan for our engineers to get ramped up on the new version control
    • Our Sr. Engineer has some experience in this so they are going to spend some time getting back up to speed
    • The other two engineers have limited experience and will work with our Sr. to help gain knowledge in the tool
  • API call POC – Done!
    • After we set our goals, the team came together and pair-programmed a solution to get a call to this API
    • This was accomplished within two hours of setting this goal, which was amazing to see!

Retro:

What did we do well?

  • Quick POC and pair programming
    • Got exposure to the XML
    • Also started to brainstorm questions for more work on the API integration
  • Beta testing went well

What can we do better

  • Look back at and bring back our production push checklist so we can think less about what we need to do when we push our solution to production.

Overall, it’s been a great nine days of trying something new on the team. I hope anything you’ve read helps you think about ways to improve your team!

(Featured Image Credit: http://changingthegameproject.com/winning-race-right-finish-line/)

 

Agile, Estimation, Improvement, Learning Lessons, Remote, SDLC, Technology, Tools

Daily Sprints – Day 7

Each morning for the next three days, I will post about the previous day and hope to provide some interesting insights on how the team is trying to improve their estimation! See Day 0, Day 1, Day 2, Day 3, Day 4, Day 5 and Day 6!

What have you tried that works or doesn’t work?!

Day 7

Every day this build, the team continues to show progress in thinking about how can we do better, even when it’s unrelated to the process of getting work done! Day 7 highlighted great examples of challenging each other for a better ways to solve problems and a bunch of collaboration between the team to push past issues.

Our goals for the day

  • UI Changes
    • The past two days, one of our engineers tried multiple solutions to solve this issue with little luck. They were understandably getting frustrated
    • Before moving on to discuss other goals, we talked about the process the engineer was taking to test their results, and we found that the engineer was taking a long time to see results, so we dove into their local testing process
      • Other engineers challenged the process this engineer was going through! It was awesome to see and the other engineer took the ideas in stride (see results & “what did we accomplish” below)
      • Examples of challenges
        • Why do you need to run all the services when the solution you are working is only using one service?
        • Why do you need to stop the services when you make changes?
      • Result: The three software engineers would spend one hour after this meeting going over the issue and thinking about what could be done – rather than the one engineer continue to try other ideas on their own
  • Message story bug
    • After we had the message solution in our test environment, we discovered a bug that needed to be fixed
  • Config switches
    • We were waiting on our DBAs to run some scripts and then needed to test those results
  • UI Integration fix
    • Issue was investigated in Day 6, now we wanted to solve the problem

What did we accomplish?

  • Config switches – done
  • Message bug –  fixed but more testing to be added
  • UI integration
    • Still working on the issue. We identified that we were missing our credentials file and now we just need to identify the file location
  • UI Changes – FIXED!
    • This was a great example of team work
    • After our goal setting meeting and the challenges towards the engineer who was taking on the work, the three software engineers came together and started to work through the local testing process that one of our engineers had been using for the past couple of days. The engineers identified two things to try that ultimately led to this story being fixed
      • One engineer helped demonstrated the waste behind running all the services, when we only needed to run the one that mattered to the solution
      • Our Sr. engineer helped point out how we could use Internet Explorer to better test CSS changes
    • After trying these ideas out, our engineer was able to solve the issue!

Retro

  • Code reviews
    • One of our engineers added a task for code reviews. This sparked some ideas if we should add these tasks to all of our stories
    • Another idea was to add a “tag” to a task to identify if the story was waiting to be code reviewed
    • Another idea that came up was adding another column to our Kanban board for code reviews
    • We are going to see if we can add a column to the Kanban board and if we can’t, add tags.
  • Talking about what went well
    • This was a great point mentioned by our BA. We’ve been using retro to just focus on how can we do better, but haven’t been celebrating our wins for the day.
    • Moving forward we will celebrate what went well, as well as, identifying what we can improve
  • Quick Business User Feedback
    • Great example of a fast feedback loop & communication progression
    • Our engineer noticed multiple data points that were coming in from different dates. The Engineer and BA talked about if we could just show the one data point or needed to show all of them based on date
      • This started as an instant message conversation and moved to a phone call. They recognized that they could get an answer from our end user
      • They called the business user to help make the decision
      • Once the business user called in, they got a quick answer and were able to finish the solution based on the feedback from our business user

Only a few more days left in our two week build!

(Feature Image Credit: http://www.corporatecomplianceinsights.com/the-light-at-the-end-of-the-tunnel-or-cliff/)
Agile, Estimation, Improvement, Learning Lessons, Remote, SDLC, Technology, Tools

Daily Sprints – Day 6

Each morning for the next three days, I will post about the previous day and hope to provide some interesting insights on how the team is trying to improve their estimation! See Day 0, Day 1, Day 2, Day 3, Day 4 and Day 5 here!

What have you tried that works or doesn’t work?!

Day 6

Day 6 started well with no major issues! Our Sr. Engineer got his computer ready for development. Everyone had ample time in their calendar to work on development tasks! Pretty great that everything was working. What I personally found interesting over the last couple of days was how often things unrelated to our solutions come up that can take down development time.

Our goals after starting the day

  • Finish writing integration tests for the messaging story
    • Found a merge conflict because a file was moved outside the unit test solution
  • UI story
    • Testing last night, hard drive space prevented her from running the services
      • Cleared about 10 gigs
      • Code review out today
  • Configuration switch for one of our services
    • This was challenged by one of the engineers on the value of this over some other work in our backlog – we did end up working on it when we looked at our remaining work.
      • Great challenge here!
  • Investigating an issue with a UI integration that is broken

What did we accomplish?

  • Integration test were checked in, but there were questions about the software solution being pushed to our test environment
    • This is happens sometimes because of the schedule of when we push work to our non-prod environments. Our teams don’t have the ability to push work whenever they want due to a number of things. It does cause issues at times and prevents us from getting a faster feedback look (this is being worked on by another team)
  • We solved the merge conflict
  • We met with an Architect to get a Git project set up and build out an analysis tool for one of new projects that we started earlier this week (the messaging story)
  • UI Story
    • This story is making progress, but we weren’t able to check in any work. This solution utilizes XSLT which is not something we are very familiar with, so there are a lot of unknowns
  • Config Switch
    • We did end up working on it but we are road blocked with a DBA tasks to see if it is working
    • This also goes back to earlier in the week about calling out roadblocks earlier so we can be better at planning other work while waiting on roadblocks
  • UI Integration investigation
    • We were able to reproduce the issue but we can’t identify the cause due to the layers of UI elements that isn’t allowing for the error to be logged correctly
    • Our engineers plan on trying to add logging or find the error logs in the coming days

Retro

  • Working in different time zones
    • This is a unique problem to an all remote team. The team has team members on East Coast, Central and West Coast time zones
    • Our BA and Engineer in central time, set a meeting for 2:30. The BA thought 2:30 EST and the engineer thought 2:30 CST
    • We decided on defaulting all times to Eastern time and leave the responsibility of “translating” that time for the team members in their respective time zones
  • Offline files continue to cause issues
    • One of our engineers couldn’t run their solution because their hard drive was full
    • The engineer identified that about 50 gigs worth of files sync every evening, and they need to delete those in order to save space
    • This is another unique challenge that our engineers face at times. The awareness around this issue was great because they helped explain what to look for and the manual work-around of deleting the files until
(Featured Image Credit: https://www.naylor.com/associationadviser/advertising-during-economic-recession/)
Agile, Estimation, Improvement, Leadership, Remote, Technology, Tools

Daily Sprints – Day 5

Each morning for the next four days, I will post about the previous day and hope to provide some interesting insights on how the team is trying to improve their estimation! See Day 0, Day 1, Day 2, Day 3  and Day 4 here!

What have you tried that works or doesn’t work?!

Day 5

Monday brought a few development concerns. Our Sr. Engineer was still getting his computer up and running. Also, Monday is Tesseract day.

Tesseract is Amrock Technology’s “innovation time” – the idea made famous by Google’s 20% time. Tesseract time is Monday afternoons and allows tech team members to work on anything related to self-learning, building innovative solutions and generally finding time to improve your skills.

Why is this important to this post? It takes half a day away from our development time (in a good way).

After starting the day, we laid out our goals with Tesseract in mind

  • Check in the messaging functionality
    • Also need to add a column in the database
  • Build an on/off config switch for this message functionality
  • UI Fix for how information is displayed

After talking about our goals our team had a great discussion about our “internal code complete” which I touched on in Day 0. The BA asked if we were trying to hit Tuesday end of day internal team code complete. A few challenges and ideas came from the team

  • We talked about spending time testing for two days (how we used to do things)
    • Challenge to this – if we have tests in place (especially if using TDD), we shouldn’t need two days for testing
    • Realistically, we aren’t using TDD on some of this work due to the work it would take to get all the testing in place (mocks/fakes) for stories that are much older – we were using TDD on a new project at the start of this build, for our messaging story
  • The topic of fixing things came up and using two days to fix things
    • Challenge to this – if we are breaking things down into smaller chunks and checking work in earlier, we should shrink this “two days” down because we are getting faster feedback when we check in early and often
    • Also, if we are writing tests (unit and integration) as we go we should know how we are doing as the build goes on

My take away from this – IT’S REALLY HARD TO BREAK AWAY FROM OLD HABITS! Habits form and they make you comfortable, even if they don’t create the desired outcome like we tried in the past. Leaders should challenge our own habits and our team’s habits, when we believe there is a better way because we aren’t seeing successful outcomes. Also, leaders should empower their team members to challenge these habits, because they may have a different point of view of the issue.

How did we do with the shorter day? (note how little we aimed to achieve this day because we looked at our schedule and knew we only had a morning or so of development time)

  • Message story was checked in and pending reviews from our DBAs and engineers
  • On/Off switch for the messaging was checked in
  • UI fixes were worked on but not completed

Retro

  • Retro was pretty short due to the shorter development day
  • Remote computers seem to have space issue
    • Two engineers are having hard drive space issues, which is causing issues for them because they need to delete files before they really can move forward
    • They mentioned how even after they delete the files the space gets filled back up pretty quickly, which is interesting because maybe there is something specific to how remote computers sync with our network compared to how in-office computers work. Anyway, this is one of those fun problems that pops up from time to time but can be pretty disruptive

On to the next day 🙂

(Featured Image Credit: https://medium.com/@JimWexler/the-science-of-habit-breaking-e3fe6177599d)