Facilitation | Our Agile Journey

January 22 2021

Something over Nothing

AdamM Agile, Agile Fluency, Facilitation, Meetings, Scrum, Teams 0

It happens to every team. The sprint is coming to an end and the team has nothing to demo. Is it because no progress was actually made? Unlikely. Usually, it’s because the progress isn’t something that can be easily shown. In this situation, most teams want to skip the demo. You can’t blame them really. The team is likely embarrassed and almost certainly frustrated. They worked hard but don’t feel as if they have anything to show for it.

In reality, there was progress made and lessons learned. The team’s concern is that the progress wasn’t what was expected. They may fear the feedback they’ll receive if they present what they have. More commonly they may feel the audience for the demo doesn’t care about progress they can’t easily see.

Many agile frameworks and methodologies are rooted in empiricism, a theory stating knowledge comes from experience. This is part of why short feedback loops are so prevalent in agile circles.

One of the pillars of an empirical process is transparency. Sometimes this is brought in as a value to the framework, sometimes as a benefit of the process, and even occasionally as a side effect. Whatever form it takes, the review is one of the places transparency is delivered.

I believe part of the problem may be a belief that only items that fit the definition of done should be brought to the sprint review. I would agree that only completed items should be given a demo, but the sprint review is more than just a demo of completed functionality. Just as a retrospective is a chance for the team to calibrate their work, the review is a chance for the stakeholders outside of the team to help calibrate the product direction. This meeting involves more than just seeing a demonstration of the increment the Product Owner intends to accept. This is a chance for the development team to see people interact with the product in real-time, a chance for the end-users to guide the future direction of the product by giving immediate feedback, and a chance for the Product Owner to learn how the backlog should change going into the next sprint. This review is part of the rapid feedback loop and should be treated as such.

There is a balance to strike here. Any work done which provides new insight or drastically changes estimates on stories is worth presenting for discussion in some form. Another idea is to show partially completed items, in a presentation format, not a demonstration, and gather direct feedback. Big decisions that could have ramifications on future work should also be brought up here. It might be useful to mention any training taken, but going over what was learned in that training probably isn’t. Small decisions made by dev team members, using an integer versus a big integer for instance, probably don’t belong here either.

Getting the team and organization to reframe their idea of what the review is for will make it a much more powerful event. When the review is about gathering feedback on the present and future state of the product then roadblocks and problems become valuable to share in that format. With the meeting turning into a collaborative feedback session the team should no longer fear showing incomplete items and discussing why. The entire stakeholder team can then provide feedback on what should be done, and the Product Owner can move to the next sprint with a great level of confidence that the team and stakeholders are aligned.

In addition to feedback, having the review work a session to go over both completed items and incomplete items increases the team’s transparency. Instead of just leaving a feature that got dropped from the sprint out a discussion on why it was dropped can happen which lets the Product Owner make an informed decision on whether to bring it back in or not. It’s entirely possible once the stakeholder pool finds out a user story has tripled in size they’re going to want to drop it down the priority list. These are some of the true outcomes you should strive for in your review.

Having shifted your team’s view of the review meeting they are not likely to want to skip it anymore, even if nothing managed to make it to the definition of done.

If your organization could use some help with their agile implementation please contact me here. We’ll have a chat and see if it makes sense for us to work together or not.

September 25 2020

Asking for Help

AdamM Agile, Agile Fluency, Facilitation, Implimentation, Leadership, Teams 0

In the United States asking for help is often seen as a weakness. Telling your boss you want to bring in someone from the outside to help you can feel like career suicide.

Unfortunately there is often a large difference between “this is a little more than the team/I can handle” and “we can justify a full-time person for this.” When a team or person first gets to where things are getting to be a bit much there is often a desire to handle it. This might be fear of looking unqualified, false confidence, or any number of reasons. The problem is often compounded by how this state can sneak up on people. One day the workload is fine, and the next it’s six months later and despite 60 hour weeks everything is falling behind.

The good news is that this perception is changing, and in many places bringing up the idea of an outside consultant to help with short or long term needs or goals is no longer problematic. This can take many forms, the most common of which is a person to do front-line work on a part time basis. Another is to hand an entire small project over to another firm.

while there’s not much more than time and repetition which can help people see asking for help as a sign of strength instead of weakness, I can go over some ways asking for help can be beneficial to teams.

The most common way a team will discover the need for assistance is when the workload in general gets too big. This is a pretty easy problem to solve. Initially, an intern or part time contractor is a way to get more hours on a project. If the need is large enough, an other person could be hired to the team. This will reach a point of diminishing returns, a team can only get so big before it should either be split into two, or a second one started. This type of help is generally needed as an organization grows and can be seen as healthy in all regards.

Another way a team find a need for help is when something goes wrong. The number of way something can go wrong such that a team needs help are innumerable. Some are good, some are bad, but that part isn’t the focus of this post. What kind of help the team needs and how to get it is. The answer here is, it depends. It highly depends on what went wrong. Trying to boil this down I’ll leave us with three scenario’s. Thing that went wrong was driven by the organization. Thing that went wrong was from within the team. The thing that went wrong was outside of both the team and the organization’s control.

When something goes wrong and it is driven by the organization the team loses trust in the organization. Any attempt by the organization to fix the problem will be met with skepticism. At this point the organization can try to hand everything over and stay out of the way. This may allow the team to fix what went wrong, but it won’t restore any trust in the organization. The relationship between the team and the organization will remain tainted going into the future. Instead of just handing things over, a better approach would be to bring someone in from outside to not only help the team address what went wrong, but why it went wrong. If possible, the team should be part of choosing the outside person to bring in. The organization needs to take this seriously, and make moves to fix problems outside the team which led to what went wrong. This will help not only fix the problem, but also restore the team’s trust in the organization. It also set the organization and the team up to be stronger going forward.

When the problem starts from within the team the organization is in a better place. It is telling that the team was unwilling to seek help from outside of itself as things were falling apart and waited until things went wrong. This comes back to trust. the team may not trust that the organization is willing or able to help them. In any event, once things have gone wrong and the team acknowledges the problem comes from within, it’s time for the organization to help the team. If the team cannot identify the problem they need someone from outside the team to come in and work with them to find it. If they can identify it, but not fix it, they again need someone from outside the team – though in this case it may just be support to make something happen. If the team can identify and fix it, then the organization may just need to give them space. Teams grow through adversity just as well as they grow through other means.

Problems outside both the organizations and team’s control are rare, but 2020 showed us they can happen to any organization. Whether help from outside the company is needed in these cases or not really depends on the type of problem, and the reaction of the team and organization. If the problem is within the organizations expertise, they may be fine without help. If the problem is outside of the organizations expertise – power grid problems at a restaurant – they may need outside help. Even if the problem is within the organizations expertise, it may be at a scale that requires outside help. If the problem has the team or organization frozen whether in overwhelm or indecision, then just as above some outside help may be needed.

The best way for a team to recognize they need help is simply knowing they don’t know something or can’t do something. Having the ability to call in an expert, even on a short-term consulting basis, is the sign of a strong team in a healthy organization. This is always a better solution than waiting until something goes wrong. If your teams have never sought out help it may be time to examine why. Often it’s not that help, even in the form of money for training, isn’t wanted but rather that they don’t feel safe enough to ask for help.

I can assist you and your teams in this conversation, as well as helping with many aspects of an agile transformation. Send me a note and we’ll have a (free) conversation about what teams and organization might need and how I can help you get there.