Blog de Joe Freeman

I've seen plenty of places where they avoided doing the repetitive work it takes to make sure that new tasks were ready to consume. They threw down work items in front of a team and told them to take care of it. This means that team didn't work at full speed during that time and missed the opportunity for some other incremental deliverable.  Great teams are like woodchippers.  We need to keep the wood stacked next to them to keep them fed. Agile has this notion of Definition of Ready, a set of criteria that must be met before a work item is ready to be picked up.  That DoR varies depending on the scope of the item, programmatic, vs quarterly vs individual task. The DoR is a checklist of criteria or check boxes that you need to satisfy in order for a team to pick it up and be successful in a short period of time.    There are two hard times when building a cadence in a project.  There is the initial time when you think you are going to just wing it and be su...

There is a great shift left  movement in software engineering that is in some ways the natural outcome of the Agile movement.  Everyone wants to push more power and responsibility onto engineering teams removing roadblocks and shortening cycle time for making changes and creating products.  This increases the number of tasks and cognitive load on those teams as a tradeoff for shorter cycle times and other concerns. The idea is that you push ownership of every facet of a product to the lowest level possible.  People often use Amazon AWS as an example of success in this area.  Originally shift-left was primarily an engineering function where you pushed all of the technical responsibilities to a single team.  The team creates better products because they own the entire lifecycle and any of the cycle times.  Organizations have eliminated adjunct positions creating a staff single developer type that owns the previous test, DevOps, CI/CD, data, and all devel...

This discussion is about what companies can do to upgrade technical skills and implement best practices to increase the quality and capabilities of delivery teams.  It is not discussing project management or cross-team delivery issues. This is mostly built on experience with Software Delivery and Development. The general concepts are probably valid for process teams that require multiple skills. Delivery Team Complexity Software delivery continues to evolve requiring ever-increasing technical expertise as system complexity, system scale, and compliance regulations increase.  Modern applications face continually evolving security threats further increasing the burden on software delivery teams.  Shift Left initiatives increase the accountability and responsibilities of the same delivery teams .    This image shows some of the roles played by delivery teams as part of historical capabilities in addition to those added as p...

Meetings have their place, especially in collaborative, consensus, or creative organizations. We need to manage the number of meetings to ensure that you have "heads down" time. I have seen at least three different ways of tackling the problem. Create a corporate or department policy. Create a daily multi-hour team meeting. Block out multi-hour blocks on your calendar. There are other ways that I've never tried. Ban all meetings Decline all meetings where you are optional. An average  calendar with some protection This calendar partially successfully guarded 4 ways.  There is a " no meetings before 9:00"  policy.  There is a daily " lunch block " . There is a " no meetings Friday afternoon"  policy and there is " team time"  blocked out for two hours every afternoon. Video Video speaker notes <to be added> Create a corporate or departmenta...

Team members are happier if we can find interesting work for everyone in every organizational period. It doesn't have to be gigantic or occupy even the bulk of the time in the period. The idea is that people feel rewarded when they get a task that implies trust in their ability or a task that is important to the team. This sounds like basic management but I've been on plenty of teams where we pigeonholed people into secondary tasks. For a Scrum software team, this may mean an interesting task in every sprint or PI. For a help desk, it may mean an interesting, off the phones, task every month. For other jobs, you tell me. Click to Expand Video Speaker Notes <to be added> Created 2022 01

I've worked for over a dozen companies across more than 20 projects.  Three team efforts stood out from the rest.  Two of the projects had  reunions or socials up to  20 years   after the project peaked . One has a Facebook group. Another has an international mailing list.  See the video below None of the projects was easy.  They all involved conflict.  All involved more than 50 hours a week at peak. Some parts were pretty miserable.  I wanted to quit and stare at the ocean.   These special projects were all personal and professional learning experiences.  They make all other employment  just work   now that I have forgotten  the exhaustion and frustration.  People go a lifetime without ever working with a group that has a reunion that draws people from hundreds of miles away. Most are shocked when I tell them I worked at  two  places where this happened.  I made friends with people I would wo...

What is the relative value of a new hire in their first year?   The value is impacted based on many factors, the hire's motivation, their prior experience, the hiring company's onboarding process, the culture fit and other factors.  Good processes can dramatically impact the contributions made by new hires.   This posting is really not about about the interview and hiring process's impact on the quality and eventual capabilities new hires.  This posting is about the general rate at which new team members contribute as measured against their eventual capabilities. My main area of experience with this is with technical teams, software developers, testers and technical analysts.  I suspect it is also true for other skill positions and integrated team. Understanding the Learning and Networking Curve The graph shows my gut feel for the rate at which team members contribute within their first year relative to their capabilities. It doesn't rate the new team...