7 Habits, Agile, Estimation, Experience, Improvement, Leadership, Learning Lessons, SAFe, SDLC, Technology, Vision

3 Tips For Your Next PI Planning

April kicked off our second Program Increment (PI) Planning event using the SAFe framework. My team and I reflected on the difference between PI 1 Planning and PI 2 Planning.

Three topics came up that we believe helped us improve our PI Planning.

Clear Socialization Purpose and Different Meeting Types

  • Understanding the purpose of socialization helped the team understand why socialization was so important and what needed to be accomplished during these meetings. This led the team to identify what they already knew and what gaps they needed learn, which led to better questions during each session.
  • Our Product Owner used a variety of socialization meeting types to produce new insights and different questions.
    1. High level, first pass – we just went over the features we intended to plan during PI Planning. This was to get our feet wet.
    2. In depth with shared services – This helped us think about our dependencies and ask questions we didn’t think of during our first session.
    3. Teach Back – Our Development Team taught our Product Owner the features we were going to work one. Any gaps in their teachings our Product Owner answered in order to finalize our preparations for PI Planning.
  • Side note: The teach back was inspired by a separate team that was planning on doing the same thing!

Begin With The End In Mind Strategy Towards Team PI Objectives

  • Identifying and clearly writing our PI objectives upfront helped the team envision our destination, so we spent the majority of time figuring out how to get there.
    1. The Development Team did an excellent job using the remaining time to come up with how to accomplish the objectives and they were able to take on unexpected work because it fit into our destination.
    2. A fourth feature was brought to us and because of our clear objectives, the Development Team knew they could commit to the feature.
  • Working closely with our business stakeholders and other train leaders to get feedback on our objectives helped speed up the process. This prevented us from getting stuck and verified we were headed in the right direction early in the process.
    1. We had great conversations about what should and shouldn’t be a stretch objective.
    2. These conversations helped us think about what we truly control and not trying to achieve outcomes out of our control.

Shorter Feedback Loops From Shared Services and Business Stakeholders

  • Leveraging our shared services with more urgency and without hesitation helped us get answers quickly and prevented major bottlenecks in the planning process
    1. Listening for key phrases like ‘I am not sure how that works’ or ‘I assume that is what was meant’ immediately triggered our Scrum Master to bring in stakeholders, shared services or other leaders to help get answers
  • Working hand-in-hand with business stakeholders helped improve ideas around the objectives to avoid unclear wording and reduced time to get business buy-in when finalizing our objectives.
    1. Also, because we were getting our business stakeholders involved earlier, they seemed more engaged and more part of the team.

What helped you in your PI Planning or what do you think of these tips? Let me know!

Photo Credit: https://www.agileoctane.com/2018/03/31/the-magic-of-safe-pi-planning/

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!


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, Leadership, Remote, SDLC, Technology, Uncategorized

Daily Sprints – Day 8

One more post for Day 9! 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, Day 6, and Day 7!

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

Day 8

Better late than never – I prioritized other work that directly impacts this team over getting this post out this AM. 😦

Goals for the day

  • Show N Tell of all the features we are pushing to prod to the business this build
  • Begin to think about technical design behind our next big project
  • Finish UI Integration issue
  • Identify if we can add a small UI enhancement to one of our solutions

So what did we accomplish?

  • Everything we set out to do the for the entire 2 week build, including in Day 8!

Day 8 was special! This was our code freeze day and a few amazing things happen – to be honest, a lot of amazing things happened over the last seven days.

What was so amazing?

  • UI Integration
    • This was a broken file due to an encryption and environment issue. The process we went to solve this problem was amazing to watch!
    • Our Sr. Engineer sent an email the night of Day 7 to one of our other Sr. Engineers to help us think through the issue. The next morning we had no response. During our goal setting meeting, I challenged the Sr. engineer to call someone to get an answer. This didn’t happen…
      • A BETTER IDEA HAPPENED! Our BA suggested we bring in people to our Zoom call and then our entire team can hear about the problem and ways we are trying to solve it so we can learn together. This was a great idea!
      • The other Sr. Engineer on the infrastructure team called into our Zoom and helped us brainstorm, but no luck.
      • We brought another Sr. Engineer in who had knowledge of this solution – no luck.
      • Finally, we brought an Architect in and they helped us identify the issue solely because they understand the differences in environments! Once the Architect helped us make that connection we solved the issue. Amazing!
  • Business Show N Tell
    • This Show N Tell was different. I think because the team was so happy at all their accomplishments over the last two weeks (as they should be).
    • What was really interesting was the reaction to the business users when we said we solved some tough technical challenges while trying a much different way of operating.
    • I didn’t anticipate this. After our BA brought up the different way the team was doing things this build, I mentioned I was blogging about the journey and sent the blog link to the leaders that were in the meeting
      • This is interesting because I often think the business users and leaders see technology as a black box. Here is a problem (input) and technology provides a solution (output). How tech teams go about doing their work is not something our business users and leaders see very often or at all. My blog posts provided a nice insight into our process, without even thinking this could be a tool for them. I hope anything they’ve read has helped them understand how we operate a little bit better.


What went well

  • UI Integration Solution and bring people into our Zoom call
    • Helped us focus on solving the issue
    • Resolved it quickly
  • Show N Tell
    • Went well and business leaders were happy without solution
  • Overall the last two weeks have gone really well
  • Team picked up some small stories at the end of the build with UI tweaks – great we could bring in some more work!

What can we improve?

  • Time box ourselves more often to reach out to help sooner
  • Bring in people to Zoom more often rather than calling – this may be a big game change for us as a remote team with 99% of team members in Detroit.

Have a great weekend!

(Featured Image Credit: http://uncomonresilience.com/winning-in-life/)
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!


  • 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


  • 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 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)