Teams

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.

September 11 2020

Distributed Team Room

AdamM Agile, Agile Fluency, Implimentation, Teams, Tools 0

“Team room” generally refers to a dedicated space where an entire team gathers. It differs from a standard meeting room in that it is dedicated to one team. Additionally, it is meant for collaborative work, not presentations.

In a colocated setting, this is a straightforward concept to understand, though, in practice, it tends to be more challenging to implement than one would expect. The benefits tend to become apparent quickly. A team communicates more effectively, and decisions are made more quickly. Outside partners find the team easier to work with as they are all in one place.

This is great as long as two things are true. First, the organization has to be willing to invest the money and time in setting up the workspace, including a short time of lowered productivity as the team settles in and makes it their own. Second, the team has to be colocated.

At the risk of dating this post, not many teams are colocated in 2020. That said, I suspect a large amount of distribution will continue even after the world moves past the current situation. On the surface, it appears the team room may be dead just as it started to gain acceptance. That begs the question, what exactly is a team room?

According to the definition found at Agile Alliance, it is a dedicated space for the entire team – not just developers – set aside from other groups and allocated for the entire project duration. It goes on to not only affirm the space is furnished with things the team may need but goes into details on what that might entail, such as whiteboards and workstations.

It is important to note that a corner of an open office is not an acceptable team room. While it may be a dedicated space, it is not set aside from other groups. The encroachment on the team of outside white noise alone would be detrimental to the benefits.

The biggest benefit is communication, with team member satisfaction along for the ride. How this benefit is achieved is through what Alistair Cockburn called “Osmotic Communication.” Basically, communication through osmosis. By being near team members, people can overhear things without trying to listen in. Being isolated from others means the team members aren’t overwhelmed with irrelevant noise. Not only are people able to chime in with no friction, allowing for a better full picture during discussions, but they are able to rapidly come to group decisions due to lowered communication barriers.

Is it possible to have a “dedicated space” for an entire team that is “set aside from others” in the organization without a physical place? How about furnishing this space with “tools and amenities the team may need” when there isn’t a physical place to set them up?

In my experimentation with open Zoom rooms, yes.

It doesn’t need to be Zoom, though it is the one I have the most experience with I am not an affiliate. The formula is pretty simple and can be implemented via other similar conferencing solutions. Here are your minimum requirements based on my testing.

Persistent video-enabled space
- A physical location is “video-enabled.”
Shared workboard
- Preferably persistent even when nobody is using it.
Easy screen sharing
Ability to temporarily invite others
Inability for others to drop in unexpectedly
Available 24/7

Some nice to haves include:

Full duplex audio
Built in file transfer
Break-out rooms

I will grant that even with this in place it can be difficult to work the same way in a distributed team room one would in a physical team room. Of course, it is also more difficult to work the same way in an open office as it is in a building of individual offices, or in a high-wall cubicle space versus a low-wall one, or in pods versus individual cubicles. Each type of workspace has its own difficulties, and all of them can be overcome as a team grows together.

Back to the question at hand then, what is a team room? Aside from the suggested furnishings, I think Agile Alliance has it pretty well defined. It is a dedicated space for the team where they gather and do their work. It is separate from other groups, and they are able to configure it to best suit their needs.

The other question, has the team room died before gaining mainstream success? I think not. In fact, I can see distributed teams pushing the concept of the team room to the forefront as the organization’s cost to support it is smaller in a virtual space than a physical one.

If you have teams trying to figure out how to become distributed, or even just trying to improve in their agile journey, call me. We’ll talk about where the organization needs them, where they are, and some initial steps to get them moving the right direction.

September 4 2020

The Song That Never Ends

AdamM Agile, Coaching, Meetings, Teams, Tools 0

Oh, we gather for the daily scrum in the morning now.

Oh, we present for the stakeholder group every week now.

Oh, we plan together for the next week after that now.

We reflect and optimize our work now.

Next sprint, same as the last one.

Sure we are agile but what has changed?

If this sounds familiar you are not alone. Every team gets into a funk at one time or another. A seemingly endless pattern of the same meetings over and over is enough to drive any team to the brink of insanity.

Team members take vacations, and it helps. Unfortunately, you can end up with the team in a pattern that no longer delivers the results expected. No matter what “flavor” of agile your organization has settled on (hopefully a custom one based on your particular need and talents but guided by work done before by others) it needs to be shaken up from time to time.

The best place to pattern-interrupt an agile team is the retrospective. In fact, that is part of the purpose of the retrospective. No team improves by sticking to the exact same pattern week after week. Inspecting that pattern nd presenting ideas for change should be the primary focus during a retrospective. It isn’t a time to examine the work product for improvement, that’s what demos and planning meetings are for. It’s a time to inspect the work process and improve that.

Who should be switching it up though? Whether your team is new to agile or high-performing the answer is the same, their agile coach. In the scrum methodology, this is often the scrum master. Without either of those roles, there should be someone who is championing the change from previous project processes to a more agile approach. That person would also be an option. If they’re too bogged down by their various roles, the person who facilitates the retrospective, or an outside facilitator/coach. I am more than happy to help in this regard, contact me for a conversation.

It can be tough to know how to switch up a retrospective, especially for newer teams. One easy idea is framing the conversations as a journey. The team is on a journey, sailing across a lake to deliver their goods. How was the weather? The waves? Did anything on the boat break? Did the destination change? Simply shifting people to look at the project from a different perspective is often a way to get them noticing new things, and opening them up.

More involved variations are also available, there are people selling kits that turn the retrospective into a mini-game. I am a huge fan of gamification and recommend you look to these for some inspiration.

If a team falls into a rut they can lose some of what usually makes agile processes really work. This is something to avoid, and retrospectives are only one way to avoid it. I’d be happy to get together, discover where you are in your agile journey, and help you get further faster. Ask for a free consultation today!

Diverse Multiethnic People with Different Jobs

August 28 2020

Cross-Functional?

AdamM Agile, Agile Fluency, Coaching, Teams 0

There aren’t many people in the Agile space who will tell you a cross-functional team is a bad idea. It’s harder to get them to explain precisely what that means.

Does it mean any given person on the team can do any given task? That every person on the team can do every task? Should we expect subpar work from a team filled with generalists?

In truth, this is not as big of a question mark as it used to be. Agile methods have been around long enough that people are starting to understand how they work regardless of framework, methodology, process, or even accreditation body.

Still, people are being introduced to agile concepts for the first time every day. Some of them are in technology, but many of them may be from other disciplines that are just starting to realize the benefits found in software development can be applied to them as well.

Of course, the question still remains for them, and sometimes ourselves, will we get quality work from a cross-functional team? The short answer is – yes.

As you may expect from the name, a cross-functional team is a team that can handle every function needed to accomplish the work given to them. What isn’t readily apparent is that this goes beyond the capabilities of individual team members to perform tasks. The truly cross-functional team that can accomplish all the work it’s given is also an empowered team. They have the power to remove blockers, make decisions, and work more closely with people outside the team that they need to.

That said, the team can accomplish every task they need. Note, it is the team that can accomplish this – not specific individuals.

One way to think of this is with the concept of a “Generalizing Specialist.” This is not a hard concept to get once you realize what it means. In fact, almost every single programmer is already a generalizing specialist to some degree. Developers have to create code that works. After they write some code, they test it to know if it works. While this is never as exhaustive as testing you get from a dedicated QA team, it is a level of testing nonetheless. As a team works together longer, these connections become stronger. QA specialists may learn how to write limited amounts of code, assisting the developers with troubleshooting. Developers will get better at asking relevant questions assisting product owners in gathering requirements. Product owners will learn about testing as they prepare for demos, assisting QA teams in their work.
Beyond getting work done, these cross-functional teams should also be empowered. If a development team needs a new database server, they should have the ability to get one up and running without going through months of red tape. When a product owner sees the backlog getting short, they need the ability to approach the customer and gather more requirements without having to sit and wait for a team of public relations personnel or lawyers to give them permission.

In case it hasn’t become clear yet, for a team to truly become cross-functional, they need something from the company they work within. They need its trust.

Trust is essential for a team to become cross-functional, high-performing, or just generally excel. This seemingly obvious concept is surprisingly difficult for many companies. On the one hand, the company is spending half million to a million dollars a year for this team to produce software for them. On the other hand, that’s a lot of money to not keep a close eye on.

What many agile frameworks, methodologies, and processes are really trying to do is create an environment conducive to this trust. They almost universally include things like rapid feedback, and close interaction between the business, the developers, and the customer.

If your organization is struggling to establish this trust, let me help. Contact me today for an initial conversation on your needs. We’ll walk away knowing how I can help you and holding the next step of an action plan.

August 20 2020

Getting the Win is Worth the Work

AdamM Agile, Coaching, Teams 0

Much like artists love the satisfaction of presenting a finished work, many people find themselves in IT/IS because they love solving problems. Also, just like art, IT/IS work can be deceivingly difficult.

Even the smallest problems can end up taking a very large amount of time to solve. However, seeing the relief on the client’s face when you deliver a product that solves their problem makes everything worth it.

Every project goes through highs and lows. While experiencing them, the highs always feel fleeting, and the lows drag on for a long time. This is true even when the lows truly are fleeting. Remembering why you’re doing a project can be difficult during these lows. Getting a team through these lows is just one thing an agile coach can help out with.

During retrospectives, we tend to focus on the challenges. Sure, we mention an accomplishment, but generally, we don’t spend a long time acknowledging it before we concentrate on how to overcome lows and prevent more from happening. In some parts of a project cycle, this can result in a negative feedback loop where everyone on the team spends their time in meetings focused on the lows. That results in people not wanting to attend the meetings, contributing less when in the meetings, and being drained by the time they leave them.

The answer isn’t to stop addressing challenges during retrospectives, that’s a big part of what they are there for. The difficulty is in finding balance. When things are generally going well, it’s easy for a team to look at the one or two issues and how to fix them. When the project feels as if it’s falling apart, it gets harder to look at just one or two specific problems. This is the balance a coach can help with.

During tough times the team needs help focusing on only the right problems and replacing the other problems with successes, no matter how small. Trying to solve all the problems at once results in slow progress. Problems get worse and potentially cascade to more. Slow progress and more problems demoralize the team and result in slower progress – a negative feedback loop. Working through these problems one at a time allows the team to focus on them and solve them faster and more effectively. Each solved problem means fewer problems in front of the team at the next retrospective. It also turns into a win.

It’s tough to remember while you’re in the low part of a project, but all projects have them, and they always pass. This is part of doing the work. Even though this is generally a small part of a project, it almost always feels like that largest part. Getting through this is 80% of getting through doing the work. Doing the work delivers the win, and that is always a rewarding moment.

I can help your teamwork through problems and find the other side of a low point in their project. Contact me now to set up a free initial coaching session where we’ll discover your needs and how well we can fit together to address them.

August 7 2020

Cloud Computing Requires Agility

AdamM Agile, Teams 0

Cloud computing has a myriad of advantages for your business. Someone else in charge of your infrastructure means you need less expertise in house allowing your employees to concentrate on what matters most to your business. It not all roses and kittens though. A provider won’t necessarily be on the same upgrade schedule as you, especially if you’re used to a very conservative approach.

When a data center needs to update, it will. When a SaaS provider has a new version to release, it’ll release. While it is true that agreements can be reached to help alleviate some of these problems, many companies aren’t large enough to either drive their provider’s direction or support a custom solution.

This is one example of where agility is needed outside of software development.

First off, I am a cloud computing fan. I spent many years working IT at medium-sized companies. They tend to fall into an interesting middle ground when it comes to IT. In small companies, the company knows they need to pay outsiders to support their internal team. Large companies generally have enough people to accomplish what is needed, and deep knowledge of having to farm out things that are too far outside their area of expertise. In many medium companies, especially ones which have recently grown from small, they tend to believe the staffing levels can handle everything, and the budget cannot. Of course, this is a generalization based on my experience and your mileage may vary.

Generally, people in the Agile coaching world are working with software teams who are building services. In this case, agility is about responding rapidly to customer needs, not locking in planning too far out, and related concepts. When I look at agility through my IT Operations background, it’s surprisingly similar. Your customer is the business you work with, not an external buyer. This is exactly the case for many teams writing line of business software for companies that need something an off-the-shelf package cannot provide. Preventing planning lock-in is similar to the need for an Ops team to be flexible in responding to changing conditions.

Cloud computing requires agility from more than just the Ops department though. Any internal software teams working with a SaaS provider knows they need to be ready to update API calls on a whim from the provider. Access to something may be lost by a security update or a new feature release. Often a solution created by an internal team will be replicated by the SaaS provider in the future but implemented in a much different way requiring retooling by the internal team.

It goes beyond IT as well. The accounting team may need to learn a new report building interface with only a month of warning. An HR team may need to jigger their job posting workflow unexpectedly. Every department in the company may need to respond to changing conditions as the customer of a cloud provider.

One remaining question might be, why? Why do we need to respond to changes from our provider? In short, because they are changing in response to their customer’s needs. Chances are, especially for a medium-sized company, you are not the only customer approaching them with ideas for improvement and needs for your business. Other companies are doing the same, and they need to move forward with what makes the most sense for them as a provider, not for you as a single customer. That SaaS provider or cloud hosting company is trying to amalgamate their entire customer base into one or two avatars whose needs they base their decision making on. If you don’t fit one of those, you may be left needing some agility of your own.

I’d love to help your team learn to respond to change faster, whether it’s changed they instigated or are responding to. Contact me for a free initial consult on what I can do to help your team go further faster.

Kanban Project Management System. Flat cartoon illustration

June 12 2020

Planning Like a Pro

AdamM Agile, Leadership, Planning, Teams 0

The idea that Agile means no planning has more or less been eradicated by now. However, many people are left wondering what level of planning Agile processes, methods, or frameworks need.

It depends.
– Every consultant. Ever.

Many “out of the box” Agile implementations you can get training and support implementing have specific guidance on what level of planning they require. The same can be said of many more generic approaches and frameworks. In a more general sense, practitioners such as myself enjoy the phrase “just enough to deliver value next sprint” or something similar. Of course, none of that really helps most people reading this right now.

The goals of planning in an Agile context are not all that different than planning in a classic context. We need to set expectations, guide efforts, control risk, and deliver value.

A product owner’s priority is the product. They want the best product possible, as fast as possible. The development team wants everything defined well enough for them to deliver a quality product, and the time to deliver that product. The customer wants value. The company wants profit. Everybody involved has some expectation, and those expectations need to me be managed. Proper planning allows all voices to be heard, a common vision to arise, and a sustainable pace to evolve.

For work to effectively result in real value there has to be a roadmap. Without knowing what is valuable, nobody knows what to work on. During planning the entire team works together to set that roadmap. Without this, people could work on functionality that is at odds with each other, resulting in bigger problems as opposed to solutions.

A big part of project management is risk management. In classical project management, this meant sticking as close to the plan as possible lest time or money slips out further than can be dealt with. In agile project management, this often means not planning things to such a detail that changing direction becomes problematic. The idea is to accept the risk of change rather than control it.

Even today everybody understands what the “death march” of a project is. Some date has to be met, no matter what. The pace is constantly quickened as issues come up to ensure the timeline doesn’t slip. This is anything but sustainable. In an agile environment, the scope is allowed to flex based on new information as it comes in. This doesn’t just mean a project can be on-time missing functionality or late with all functionality. It also means a project could release with functionality nobody envisioned until part-way through, and what was once thought important may be left out as all parties realize it was not needed.

How do we use that knowledge to fix our current planning sessions?

Listen to the entire team, not just the one who the product is for. Don’t look at the moon in your pocket and promise Jupiter. Be open to altering the plan as needed over time, and make sure everyone knows their input is actually used in planning.

Like many things in an agile environment planning is a team effort. If you’re struggling to see how the planning your team does matches with their reality, give me a call! We’ll talk about the disconnect you feel and how I can help you and your team close the gap.

Theatre concept with the white plastic masks

June 4 2020

Who are You Taking to Work?

AdamM Agile, Leadership, Teams 0

In the USA it’s pretty normal. Five days a week we get up, go to work, and then come home. The other two we don’t – usually. (Hopefully?)

In doing this, many people speak about “leaving work behind” or “separating work and home life.”

This is important, in some sense. You need to leave the stress of work out of your home as much as you can, in some professions even more than others. At the same time, you do need a place to safely decompress work, and that’s often at home.

Leaving home and going to work at the office. Leaving the office and going back home. It’s very normal and common. Until it isn’t. And it turns out it’s not necessarily a bad change.

May 27 2020

Change is a Constant

AdamM Agile, Teams 0

Everybody knows the quote.

“The only constant in life is change.”

– Heraclitus

What does it mean though? Specifically, what does it mean for a team?

I often remember this quote when someone references Tuckman’s stages of group development. Most of the time the stages are seen as a journey. At the end of the journey, the team becomes Performing and corporate Nirvana is reached.

As a coach, one of my primary roles is to help teams improve, or help them become performing. These stages and a team’s ability to move from one to the next is a huge part of the value I can bring to a company. Of course, the idea of a team constantly moving along this path to arrive at Performing and live there the rest of a companies life is, in a word, fantasy.