Agile Fluency

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.

November 9 2020

Individuals and Interactions

AdamM Agile, Agile Fluency, Back to the Basics 1

Start with what matters most.

If we assume the signatories of the Agile Manifesto did this then what matters most is spelled out by the following opening:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and Interactions
over
processes and tools

The manifesto starts not with a list of practices or methodologies but a statement that people are the most important. What process you follow and what tools you deploy pale in comparison to the importance of the people doing the work and their ability to work together.

It makes practical sense too. Any process or tool will only be as good as the people using it. Any group will only work together well if they also interact well. The project is bound by the people on it just as much as it is bound by the time and budget allotted.

This is the second in my series on the Agile Manifesto in the run-up to the 20 year anniversary of its signing. We’re diving into the concept of Individuals and Interactions to get an idea how to make sure your team keeps them more important than Processes and Tools.

Tools are useful, but they are also limited. A tool is only as good as the person who uses it, like this bowling ball.

In the hands of a different person that would have turned out very differently. In her hands with the support of a team that works together, that would have turned out differently as well.

One indicator of problems in a team is when the tools start to get all the blame. It doesn’t matter how good or bad your project management system is. If the team is unwilling to run work items through it properly, it will fail. Instead of pounding into the team how they need to use the tool, step back and look at the team. Why aren’t they using the tool properly? Is it simply training, or is it because as a team they work well in a way that isn’t supported by the tool? Perhaps your tool requires a very linear process and the team members who have a more lateral approach are struggling to use it. That team member, that individual, is more important than the tool. This should factor into your approach to resolving the situation.

Just as important is making sure interactions within the team are healthy. A good indicator here is whatever your team’s form of a retrospective is. If the retrospective is failing, then there is a problem. It may be the style of the retrospective, but likely it’s interaction on the team. If the team members don’t feel safe in the retrospective they will not give honest feedback and growth will be very difficult to come by. Have a mini relaunch of the team. Validate the current working agreement and goals of the team, make sure they are still relevant.

This ties in closely to the concept of treating people as people, not resources. I’ve long wondered how much harm was done by moving from “Personnel” departments to “Human Resource” departments. The shift has many implications, putting the organization before the employee and treating people as inputs to a machine are two.

Stop looking for resources, start looking for team members. Make sure you value those team members and their ability to work together more than the tools they work with or the process your organization follows. This is an important step on the way to thinking with agility, and arguably the most important of the Agile Manifesto Values.

If you’d like some help making sure your team is valuing people over process book a call with me here. I can help evaluate your teams based on your concerns and provide steps for reaching agility that is specific to your organization.

November 2 2020

Where Are You Going?

AdamM Agile, Agile Fluency 0

Your company started small. Maybe it was one team, maybe a couple of teams on a single product. That was few years ago though, and now it’s spread throughout the entire company.

Agile… Scrum… Kanban…

It’s spread beyond the product development teams. You hear Marketing and HR talking about Agile as you pass through on your way to the lunchroom.

Your Scrum Masters haven’t had advice for the teams in months. It hasn’t been easy, and the cost was pretty high. Management resisted a little, but the model has made steps very clear, maturity means going all the way. Nobody wants to be less mature than they can be. Even better, you’re pretty sure your team has made it.

Full. Agile. Maturity. Agile Nirvana.

Of course, we all know that’s not possible to achieve. What we need to think about is whether it’s even something to strive for.

I’ve always believed in using the right tool for the right job. That used to mean things like using a Mac for creative work and a PC for spreadsheets. The world is not nearly this black and white anymore, and honestly it probably never was. These days it often means sometimes Scrum is a good starting point, but other times Kanban makes more sense.

I heard a phrase from Ahmed Avais, founder of Agile 7, in the last year and it’s really stuck with me. Before we go any further, you’ve got to check out his work. I give him all due credit. The phrase was “Agile fit for purpose.”

“All models are wrong but some are useful.” – George Box

This quote comes up when talking about models a lot, so it’s useful here too. We’re going to talk about a model that helps you shape an organization’s agile transformation. One that you can use to help teams get better faster. This isn’t another maturity model where everyone tries to become the best though. This model is about fluency and finding the right level of fluency for your organization.

In a fluency model, the goal isn’t passing a test. The goal is exhibiting proficiency in a skill at all times. In language, a person has varying levels of fluency depending on how well they can maintain their grasp on a language under various levels of stress. Maybe they can read and write German, but not speak it. Given the chance to slow down, they may be able to communicate in Spanish perfectly, but it may only be French they can communicate in under duress. They are more fluent in Spanish than German, but not as fluent as they are in French.

The biggest argument for a fluency model versus a maturity model is that a maturity model implies every team should strive to make it all the way to the end. Anything less and the team is immature and ripe for improvement. A Fluency model assumes that each stop along the path is a place where a team can become fluent. One stop is not inherently any better or worse than another stop.

Go back to our budding linguist. If they only need to read and write German, why should they spend a lot of time learning to listen to and speak it? Will they be significantly better at reading and writing it if they can also speak it? Will the investment of time and money on learning to speak it help enough with writing it to make sense?

These are the things I’m thinking of when I start looking for what purpose a company has, and how would Agile best fit for them. I’m not looking to push them to the far side of a maturity model. That may be more than they need, a waste of time and resources. Instead of blindly following a maturity model to the end, they should look at what level of agile fluency fits their purpose.

What is this fluency model I use to help them find it? The Agile Fluency® Model.

This page of The Agile Fluency website is a great resource for learning more, as is contacting me for an initial free consultation. I’ll give a couple of highlights below, but there is also a video and an article linked out from there to get much more detail.

The first highlight is fluency over maturity. Fluency is a state of having achieved skillful practice while under pressure. It is achieved through deliberate practice. Individual fluency contributes to team fluency and team fluency contributes to organizational fluency.

The next highlight is that not all organizations need the same thing. In The Agile Fluency Model we talk about Focusing, Delivering, Optimizing, and Strengthening as different target zones. Each zone requires a different level of investment and has a different length of time before that investment will pay off. Different organizations, even different business units within larger organizations, will need to target different zones for different reasons.

There is a lot more depth and detail available here. My point today is that each organization has different needs and coaching will help them realize what they need to do to get the right level of the right flavor of agile for their situation.

Get in touch with me here to set up an initial call and talk about your needs and how I can help, whether you have only a couple of teams or multiple business units in your organization.

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.

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.

July 21 2020

Sometimes Being Agile Means Not Releasing

AdamM Agile, Agile Fluency, Implimentation 0

In Scrum there is a concept of canceling the sprint. This is not done often. I suspect many people would see it as failing in some fashion, an indicator of problems. I posit that this action, or a similar one in a different framework, is a sign of a strong team that is very fluent in their Agile practices.

The modern business world is fairly harsh on failures. The problem is, success rises from failure. Sure, we’ve all heard of Edison’s success in proving how not to create a lightbulb before he finally landed on a process that worked. Even in nature, we see massive new growth in areas devastated by wildfire – something many would see as a failure to protect those areas.

The same concepts apply to agile product teams and organizational agile transformations. Sometimes, things don’t work. We can learn from those times and discover something even better on the other side.

A classic product team will bring a product all the way to the market before allowing for a large change in course. Sure, there may be small adjustments along the way, but since Mr. Jobs gave us permission to tell the customer what they want the core idea will be held sacred. The problem here is that it is very difficult to get a customer to buy something they have no idea they want. Usually, the company ends up with a product that fails, not one that changes customer behavior. This isn’t the end for a company. They can learn from the situation and build a new, better product.

What if there’s a better way? What if they allow the core product to change earlier on? What if the product failure looks more like a meadow or copse of trees burned down than a whole mountainside? You may argue the re-birth won’t be as dramatic. While I’d suggest you’re taking the analogy too far, the answer is that each iteration of the product is like a new section of the mountainside being burned out and re-born. In the end both approaches result in a whole new mountainside, but in one the majority of the land was available for use at all times. In the other massive devastation caused mudslides and greater damage downhill.

Allowing the product team to iterate smaller parts more often will almost always result in products that are more aligned with the customer needs at a faster pace. Disruptions of changing products are minimized while benefits are maximized.

In a similar fashion, trying to change the product development process of an entire organization in one fell swoop versus a little at a time can be devastating. (Though I do reserve the right to define “little at a time,” I am a consultant and we love “it depends.” 😉 )

There are times pulling of a band-aid is better than peeling it back. For modern businesses in the largely unforgiving climate we now find ourselves in, this may not be as often as we think. While Agile processes are all about embracing change, successful ones do it responsibly. This applies to the process of becoming agile, or executing on the promise to deliver products.

If your team is struggling to find the right balance between large and small changes contact me. I work with teams and organizations to help them do better where they are at.

July 3 2020

What You Need, Not What You Want

AdamM Agile, Agile Fluency, Implimentation, Project Management 0

It can be hard to understand why Agile is preferred in some situations, especially to someone who has seen success with classical project management. And don’t get me wrong, there is plenty of success with classical styles in the past, and plenty more in the future. Just as not every flavor of Agile is right for every situation, Agile itself is not going to be right all the time. (Though I content it’ll be right most of the time, and even when it isn’t it has things to offer.)

One of the biggest benefits is that an Agile project will deliver what is needed before delivering what is wanted.

Of course, we all have “wants” in our projects. We also have needs in our organizations, and while there are times they line up, often they do not. Steve Jobs said, “People don’t know what they want until you show it to them.” Agile processes help us bring wants and needs into alignment.

May 11 2020

Fit for Purpose

AdamM Agile, Agile Fluency, Implimentation 0

There is nothing inherently wrong with a square peg. They have merely been vilified by the industry of round holes we find ourselves in. If you have a square-shaped hole in your organization you need a square peg.

I know, what in the world does this have to do with Agility?

One of my favorite models for corporate agility is the Agile Fluency® Model. In this model, there are four different destinations a corporate might land in.

The details are important here. It is not four levels of maturity to go through. While it is true that to get to some destinations you will have to go through others, they are not levels.

April 29 2020

Agile Snake Oil

AdamM Agile, Agile Fluency, Red Flags 0

Doing more with less is a common goal of companies in the modern age. The goal becomes more important during times of crisis, and inevitably after a time of crisis some effort is put into sustaining a new normal where more is done with less.

For teams in fields such as software development or educational materials development that often entails settling on some specific implementation of Agile that the executive leadership hears about from a salesperson.

Don’t get me wrong, salespeople are valuable and I appreciate what they bring to the table. Heck, I am a salesperson for my own coaching practice. That said, every salesperson has a bit of an agenda when they make recommendations – including me.

In the Agile space, that could mean a person is trying to get you on SAFe because they are certified to train you and get paid a healthy sum to do so. They might tell you to go with a Kanban system, and then tell you they’d be happy to train you how to get it in place.

Snake Oil salesmen sold stuff that may or may not have been useful, and may have actually been harmful. they did this knowingly. This isn’t how most people in the Agile space work. Most people who have been exposed to true agility believe in the solutions they’ve used and they’ve seen them work. None of these systems is inherently bad, but the question that needs to be answered is if it’s right for your situation. If the person presenting to you only trains one method, chances are that’s the one they suggest as best for your organization.

What if there’s a better way?

There is.

The Agile Fluency® Project has a diagnostic available that is independent of any methodology. The process a facilitator will take you through uses popular frameworks and methodologies as a reference but doesn’t dictate a specific one as your solution. What’s even better, is that the process includes discovering what kind of agile journey is best suited for your company, not just focusing on whatever the current industry-standard “best” level of agility is.

I am licensed to bring your teams through the process, finding out what the company expects, what the teams are capable of, and where improvements need to be made. Not only that but I am able to do this with fully distributed teams.

Contact me today to set up a free initial consultation!