7 Habits, Agile, Agile, Experiment, Focus, Goals, Improvement, IT, Leadership, Learning Lessons, PI Planning, Release Train Engineer, SAFe, Scrum, SDLC, success, Technology, Tools, Trying, Vision

Prioritizing for I & A and PI Planning

A few weeks ago I started a new position called Release Train Engineer(RTE). This role is responsible for facilitating the Agile Release Train (ART) moves efficiently and executes effectively.  

When I started the position in late June, I had 2.5 weeks to get prepared for the two most significant events within the Scaled Agile Framework (SAFe) that fall on the same week – Inspect & Adapt workshop (I&A) and Program Increment (PI) Planning. I & A is the final event during the PI and PI Planning is the kickoff to the next PI. I & A is an opportunity to celebrate all the great work done in the past PI and identify ways to relentlessly improve for the next PI. PI Planning kicks off the next quarter to determine what work can get accomplished within the PI.

I quickly realized with my end goal in mind (a successful I & A and PI Planning) I needed to identify what was the most important (and urgent in this case) things to get done and prioritize those items accordingly. (side note: in the future, I hope to find ways to move some of these items into quadrant 2, so they are less urgent and just as important)

Here is what I did to get ramped up and successfully facilitate I & A and PI Planning

  1. Identify the right people – Making sure I knew who the Product Manager (PM), Product Owners (PO), Scrum Masters (SM), Solution Architect and Software Architect were, was my number one item. This was my top priority because I needed to understand what work was going into the next PI Planning and understand how the current and almost completed PI was coming along. Asking questions to the right people would help me understand the most important information in a short period of time.
  2. Understanding the features being brought into PI Planning – This was my second highest priority because the RTE needs to make sure these items are ready for PI planning. The RTE doesn’t control this work and due to this, they should make sure features are as ready as they can be before PI Planning. If the features are not ready, the RTE needs to facilitate their readiness. In this case, we had a few features intended on being ready for PI planning, but one feature needed to be broken down. The PO and Architects did a great job of working in the last two weeks to get this feature broken down in a way that multiple teams could work together, rather than dumping all the work on one team.
  3. Making sure socialization happens and is helpful – Socialization is hard but important, which is why as a new RTE I wanted to make sure this was happening and going well. Socialization is a proactive preparation approach to PI Planning. If the features aren’t ready or unclear, socialization will suffer because the team will get bogged down by questions and may cause confusion in the future. A lack luster socialization will create inefficiencies in PI Planning, which can slow down a very fast paced two days (you can read my last article here about socialization).
  4. Brainstorming the I & A narrative – I & A is an opportunity to tell a story about the train’s journey during the PI. It is not a time just to dump data or point fingers. It is a time to improve and part of that improvement is to understand the context behind what happened in the PI using data to help elevate the narrative. I chose Grit as the anecdote to tell the story. The team has a ton of passion about Appraisals and persevered through many challenges. The data helped show how a lot of great things were achieved, despite the challenges throughout the PI.   
  5. Understanding data – Data can be dangerous if used incorrectly or misunderstood. As a new RTE who was not part of the train in the past, I was unsure what data was being looked at and measured throughout the PI. I talked with several of the right people (like the Scrum Master) to understand what they were or were not tracking. Also, I bounced ideas off other RTEs to identify what data made sense to use. I used a handful of data points in our I & A: Capacity Allocation – Planned versus Actual, Train Velocity – showing how work from another PI came in throughout the PI, and Cumulative Flow Diagram – showed how our cycle time was pretty good despite lots of unplanned work.
  6. Reviewing the SAFe site – When I started, I had a working knowledge of SAFe and the RTE role, but I am always learning and finding new information. In fact, I referred to the SAFe site on a regular basis when I was a Scrum Master. As I began to prepare my presentation, I constantly referred to SAFe’s site to make sure all my presentations hit on the major items needed for both events.
  7. PowerPoint – Creating my slide decks was really the last thing I did, BUT it took way more time than I anticipated. PowerPoint is not something I use often because I don’t give a ton of presentations and when I do use PowerPoint, I don’t make a bunch of slides. This time around, I knew I needed more information on the slides especially because of the Problem-Solving Workshop. Despite the time I spent working in PowerPoint, I still believe it made sense to prioritize this last because everything else I did before this gave me the content, I needed for my slide deck.

Image credit: https://www.developgoodhabits.com/eisenhower-matrix/

Advertisements
Agile, Experience, Leadership, Learning Lessons, SAFe, Team Building, Tools

SAFe Team Self-Assessment Experience

Our company recently adopted the SAFe framework. One pillar of SAFe’s House of Lean is Relentless Improvement. There are many ways to identify areas to improve – retro, inspect and adapt, iteration review and system demo just to name a few.

Another tool that SAFe provides is Team Self-Assessment.

When I started looking into the tool, I noticed there wasn’t clear direction around how to use it, just a short description of the tool’s purpose. I started to think:  

  • Does each team member take this and then I average the scores?
  • Do we take this together, like sizing, where we all agree on a number?
  • Do I want to get a quick snapshot here, or have the team kind of think about each question (with a timebox either way)?
  • Am I over thinking this in general?
  • How often should this assessment be taken? Once a PI, multiple times? Once every other PI?

I started to do some research on implementation practices and I found an article with great ideas.

  • What I liked
    • They suggest doing this as a team activity, rather than having people take the assessment and submitting it back to one person
    • They used an external facilitator, so the entire team could focus
    • They used a planning poker cadence (everyone says their number at the same time) using post-its & time boxing each question
      • Also, they used posters to represent each category and placed sticky notes along the axis (see pics in the post)
  • Questions that remained
    • Does it make sense to do this more often than once a PI?
    • How does this work with remote team members?
    • How does the scoring work with a poker cadence? Discuss it to meet somewhere or just average the scores?

This article helped me think about implementation, so the team took the assessment last week and here are some more takeaways from our experience.

Our Implementation

  • We took the assessment after the second of six iterations in our first PI (after ~1 month)
    • I originally planned to do this each month, to get a good idea of how the team is working within the PI
  • We used Zoom to facilitate discussion (3 remote team members and 3 local team members)
    • Everyone had a working webcam
  • I shared my screen as we went through the excel sheet, to be transparent and visual
  • We spent ~45 minutes going through the entire assessment (keep in mind, this was the first time we did this)
    • We counted down 3-2-1 before giving our score using our hands
  • We posted individual scores on the webcam using our hands; fist = 0 through five fingers = 5
  • I quickly average all the scores and marked them on the excel sheet
    • I then asked for any comments, especially at the extremes of scoring
    • I tried time boxing discussion 2-5 minutes so we could keep moving

Our Learning Lessons/Feedback

  • Some questions were not applicable because we didn’t complete that SAFe event yet or haven’t completed the PI yet
    • Example: “Team reliably meets 80-100% of committed PI Objectives’ business value” – we only completed 2 iterations so we couldn’t answer this question
  • Some questions seem more like a true/false answer or simplifying the scoring may be needed in the future
    • Example: “Team participates in System Demo every two weeks, illustrating real progress towards objectives” & “CI, build and test automation infrastructure is improving” could be true/false answers
    • A 0-5 scale is rather large for short questions in this format. It may make sense to modify the scoring scale to simplify the assessment. Maybe 1-3 like The Five Dysfunctions Of A Team assessment (1 = Rarely, 2 = Sometimes, 3 = Always)
  • The discussion after the question is more valuable than the actual answers to the questions
    • One of my team members made this comment and it was insightful because everyone can interpret the questions a little differently. So discussing the questions after the answers helped everyone think about the question and how the team can improve

Overall, this assessment worked well after the first two iterations. It helped the team take a step back from the day-to-day and think about the bigger picture. Also, I think this tool is useful multiple times per PI, but you need to modify some of the questions. Lastly, I think the next time my team is in-town, following the other blog post about using posters and post-it notes to take the assessment is a great idea that I want to implement.

If you have any questions, suggestions or other experiences, please reach out and let me know!

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!

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