A business without a customer is a business doomed to fail. While it may be arguable who the customer is, there is a customer, and they are the driving force behind business decisions.
One reason businesses experience growth stagnation is the loss of clarity on their customer’s needs. Other growth inhibitors include serving the wrong customer or focusing too much on the customer’s wants. Regardless of your business vertical, these problems are real, and real solutions exist for them.
Solve the Customers Problem
You are in business because you solve a problem for your customer. The thing is, you may be solving a different problem than you realize. The early days of UnPakt.com give us an example. They started out trying to make booking movers easier for people trying to move. They thought the problem that needed solving was central access to booking movers, similar to a central booking site for flights. When their expected growth did not come, they had to re-evaluate the actual problem they needed to solve. How did they find the right problem? Feedback loops.
The problem you think you’re solving for your customers may not be the problem they’re solving. Alternatively, it may no longer be the problem they want solved. Implement feedback loops to identify the problems you are solving and the problems your customers need solved. Act on your findings, and keep seeking feedback.
Know Your Customer
Your customer is the person using your product to solve their problem. If you don’t have a customer avatar, that’s an excellent place to start. You may have customers you don’t realize, though. Sarah Moore’s interview with Shaan Puri has a great example of this. In it, she mentions that what she initially perceived as an “egg company” was actually a specialty packaging company where “40% of our business comes from things entirely unrelated to eggs.” (https://shaan.beehiiv.com/p/1-woman-50-fake-ids-egg-business) As she got to know the business better after purchasing it, she realized her customers were not just chicken farmers but anyone who needed specialty packaging.
If you ignore 40% of your customers, you’re leaving a lot of opportunities on the table. All customers will pay more for a better solution to their problem, especially if they are an edge case. With proper feedback mechanisms, you’ll have a feel for who your customers are. If you see organic growth of new customer verticals, it’s worth taking a step back and looking for the opportunity. For instance, Nvidia is seeing fantastic growth by shifting its focus from consumer graphics cards to business-focused AI cards.
Watch for novel uses of your solution worldwide, even if it isn’t your product, and you may unlock many new opportunities for your company.
Know the Real Problem
When Business Insider talked with Kaite Dill, VP of Design at Lyft at the time, about Steve Jobs’ famous statement that customers don’t know what they want, she mentioned the importance of observational feedback over solicited feedback. (https://www.businessinsider.com/steve-jobs-quote-misunderstood-katie-dill-2019-4) The idea is that asking people what they want to change about a product will sometimes yield different results than observing what they do with it.
The classic example is people wanting their horses to go faster but not having the imagination to conceive of the automobile revolution hastened by Henry Ford. This is an example of pursuing the solution instead of the problem. When we solve a customer’s problem, we do it by providing a solution. The trick is how we come to that solution.
The most obvious way to solve a customer’s problem is to ask what they want and provide it. There is nothing inherently wrong with this approach. In fact, as it involves a feedback loop and concentration on customer value, there is a lot right about it. To truly scale and innovate, something more is needed. Feedback has to come from beyond customer reviews and surveys. Some of it can come from observation, but even that has limitations.
Imagine you run a hammer-making company. You are going to favor solutions that require the use of a hammer. You may find solutions to problems customers didn’t think of, but they’ll still be through the viewpoint of having a hammer to sell. You’ll need to think beyond the hammer, the faster horse, to truly innovate. Try bringing someone in from outside to help observe your customers and find solutions. Their fresh perspective could be just what your company needs.
Some companies struggle to move past growth plateaus; some struggle to stay relevant in a rapidly changing environment. Any company that does not have a feedback loop is doomed to fade over time. That may be from losing customers as their needs change or a new solution emerges elsewhere. It may be from a dwindling customer base when there is a world of other customers that need the solution.
If you don’t have feedback loops in place, get them. If you aren’t sure where to start, contact me. We’ll set up an introductory call. I can help you discover your true customer, the problem you actually solve for them, the solution you really have, and ways to get valuable feedback loops in place so all of that can grow and change as our world does.
When’s the last time you worked towards, accepted, and released a Minimum Viable Product?
Minimum. The least you can do. No more than absolutely necessary.
I’ve often felt this is one of the more difficult concepts to get momentum behind. This has long baffled me. The logic feels very sound to me. Deliver the smallest complete product that delivers value, gather feedback on it, tweak the direction of the final product, and deliver the next smallest complete product delivering value based on this new direction.
Side effects of doing this properly include less time spent on things the market doesn’t care about, increased customer satisfaction with the product, faster ROI, and greater team satisfaction. Why don’t teams and companies want this? I can’t claim to have all the answers, but I have a couple of ideas.
In the United States children are taught to do their best, never give up, always finish what they start, and the list goes on. The idea of haphazardly putting together something that barely passes muster goes against the culture. Of course, that’s not what MVP is truly about – but it sure can feel that way.
By the sheer nature of the word “Minimum”, the concept is already facing an uphill battle for acceptance. Minimum doesn’t delight customers. Minimum doesn’t win awards. It’s not a market leader. From early on we’re told to do our best, not the minimum. The problem here is that a false narrative has been accepted as true, that minimum is equivalent to rushed, shoddy, or some similar term.
It’s not a hard narrative to accept. A minimally cleaned house isn’t a nice as a house that’s been given a solid two-day spring cleaning. When someone does the minimum required to build a dog house and their work is put next to the work of someone who went above and beyond, almost everyone will pick the latter as best.
The problem lies in what happens before that moment of presentation, and the context of the presentation. That house? If it was being cleaned out for a remodel then the spring cleaning becomes overkill and wasted money. That custom doghouse which went above and beyond took weeks of labor and hundreds of dollars of materials. The simple one took an afternoon and $50. If the goal was a doghouse to sell for under a hundred bucks, which is more likely to succeed?
A minimum viable product isn’t about avoiding doing what is best, it’s about finding what is truly best instead of pursuing what is assumed as best.
That leads us to the other thing I feel we fight against when we try to push for an MVP approach, a little thing I like to call BDUF – Big Design Up Front.
Of course, this is near the core of what Agile methods and practices are fighting against. It’s the mentality Agilists mean when we toss around terms like “Classic Project Management” or “Waterfall.” The fight here is against the idea that a product can be completely planned out from day one and succeed. Instead, we try to embrace the fact that we cannot know until we do some testing, and producing an MVP is part of that.
Imagine a dart competition. Two people each with an identical dartboard. They both stand 20 feet back with everything needed to assemble darts. They are given an hour to make a bullseye. Those classic approaches would include taking a lot of measurements and spending a large amount of time creating the perfect dart to throw and get the best score possible. The have an hour to produce their product, so they will likely take an hour to build it. The agile approach eyeballs it, puts together a passable dart, throws it, modifies their design based on the result, and throws again. They do this as rapidly as possible for the entire hour. At the end of the hour, there’s a chance the first team will get a better score, but it’s a small chance. The second team is much more likely to get the better score.
This is the point of an MVP. You get something that will at least meet the need, gather feedback on how well it meets the need, adjust based on feedback, and make proper modifications to get closer to the “right” solution.
There have been many numbers tossed around about what percentage of a software solution doesn’t get used. I’m not going to quote any as Abraham Lincoln once told me anyone can make up anything on the internet. I do think we can all agree there’s a level of truth in those numbers, and if we look hard enough there are a couple of studies behind them somewhere. I only bring them up because this what MVP is fighting. Whatever that percentage is, that’s the percentage that was more or less wasted work by the team creating the software. With an MVP approach, the team will get enough early feedback to lower that percentage dramatically. The goal is to eliminate that number completely. The reality is that we get a little closer with each step of our journey.
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.
“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.
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.
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.
It comes back to how much planning is done when, and what kind of change control is then implemented. In a rigorous, change-averse, classic setting then what you ask for upfront is what you’ll get. It doesn’t matter if by the time development is done you’ve realized some initial assumptions were wrong, you’ll get what you get and you won’t throw a fit.
The flip side, constantly reacting to one emergency after another, is just as bad. With no overall direction, you aren’t producing a product, you’re fighting a losing battle against a raging forest fire.
Somewhere in the middle is the Agile process that’s right for your organization. Some planning is done to get a big picture idea of what is wanted and needed. Some of it is created and presented for feedback. Lessons are learned, adjustments are made. The project slowly shifts from the initial assumed goal to a better goal, one more in line with true wants and needs at the time the product is released.
Let me help you find the right mix of methods for your organization. Contact me today so we can chat and see where the fit between your organization and my support is.
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.
Most models present levels of Agile maturity, highlighting a common path from beginner to expert. The implication is that all organizations should strive for expert-level agile implementations. Often these models are coupled with specific methodologies that will get an organization from one level to the next.
James Shore and Diana Larsen felt something was off with this model. Over multiple years they collaborated with many other practitioners and leaders in the agile community as they tried to define a better way. One of the core pieces I love about the model they eventually described is the idea that not every organization should strive to have a fully agile system implemented expertly.
On the surface, the model is fairly simple. With no Agile practices, a team is not yet on the chart. As a team brings in more practices and gains fluency they move closer to one of the destinations.
This is where the magic in this model happens. A team will move toward a specific destination, a destination that makes sense for them and the organization. One which the organization can commit to helping them achieve. They are not under pressure to make it to some expert end state, they are allowed to excel as experts at the proper level of agility for them, and the company.
Of course, some methodologies are mentioned when an evaluation is done, but they are not set in stone action steps. Those come after discovering where the organization wants the team and where the team is. The methodologies are used as stepping stones to achieve fluency, not as an end goal.
If you are ready to discover where your organization really needs teams to be, contact me for an initial conversation. I will talk with you about what the model can and cannot do for you. We will get a chance to see if we are a good fit for each other, and the end result can be a chance to help your teams deliver more value to your customers, and do it faster and better.
How does middle or upper management sell doing Agile to a team that may not be too excited about being told to change how they work?
In most Agile transformations the biggest hurdle is the people who are not on board. When Agile is pushed down on existing teams, those teams can become that hurdle. What starts as a plan to improve customer value, delivery cycles, and employee satisfaction turns into a fight between management and employees. This is not a new problem. Martin Fowler, one of the original 17 creators of the Agile Manifesto, said in a blog post on October 2, 2006:
Drifting around the web I’ve heard a few comments about agile methods being imposed on a development team by upper management. Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception. http://martinfowler.com/
Basically, Agile pushed in a prescriptive manner misses the point. The problem is companies all over are seeing real value from Agile transitions. On top of that, team satisfaction in Agile environments is generally higher than satisfaction at your company. The real question now is how do you bring your teams on board?
The most important thing to do first – figure out why you are pushing this transition on the team. Is it being mandated to you? Are you seeking higher performance? Are you chasing the latest trend? Are you trying to deliver more value? This is important. This will form the basis of everything that comes next. That’s because Agile is not a specific set of processes, tools, and techniques that the teams must follow. It is a way of approaching work that values people, collaboration, flexibility, and results over strict plans and tools. Use the reason and Agile Manifesto values to create a vision that you can sell to the teams.
With the knowledge of why you are pushing this transition you must know how important the specifics you initially proposed are. If you’re lucky they aren’t important but instead are flexible. If you aren’t lucky you are being forced to push a specific set of tools and practices down. You can work with either of these.
The next step is to realize that Agile requires a different kind of leadership than you might be used to. Instead of directing everything the Agile leader sets a goal, or a vision at higher levels, and empowers their teams for success. Take attempting to release to production more often as an example. In a classic leadership model, leadership is going to decide that the latest release of the development environment enables shorter cycle times and then dictate that everyone now must move to it. Maybe they read about it in a white paper or heard from a colleague. In an Agile environment, leadership is going to tell the team that there is a goal for more frequent production releases. The teams will come up with solutions. They may or may not include the latest development environment. They may not even be the same across the teams. Leadership is going to work with the teams to make these solutions a reality, inspect the results, and adapt as necessary.
With our goal in mind, and knowledge that Agile requires a different approach we now have other issues to address. You might be pushing a specific methodology because your management has dictated it. This needs to be part of bringing it to the teams. Assuming this methodology is a true Agile one then also bring to the teams the idea of continuous improvement. This may lead to a realization that the teams just don’t understand Agile.
Most often this can be seen in corporations where the project managers all get sent out to learn scrum. They take a two-day class, a test, and then come back chomping at the bit to put their new knowledge to work. If they have a lot of energy and the personality to back it this can force change, for about a month. It will also cost them trust afterwords. Everyone involved needs at least some training in what is happening for it to work, scrum or not. You may not need to send the entire team to get certified, but at the very least they should be given resources to learn the basics of the Agile Manifesto and how the chosen methodology fits in.
If training alone leaves the teams still wary, then applying some of the same logic Mike Cohn suggests for selling Agile to bosses can help them see a bigger picture.
Let’s return to your attempt to convince your boss to let your team use Scrum. Imagine you had focused on the benefits of Scrum rather than its features. You told your boss how using Scrum would lead to more successful products, more productive teams, higher quality software, more satisfied stakeholders, happier teams, and so on.
i.e. – Instead of just telling them to have daily stand-ups, tell them how daily stand-ups will benefit them.
After all of this, the most important thing is trust. The teams have to trust that leadership will not get in the way of the Agile transition. Leadership has to trust that the teams will work the system instead of going through the motions. As the leader looking for change you must show that you trust the team before the team will trust you. Without trust, the Agile Transition will be long and difficult.
Often organizations will start an Agile journey by sending their project managers and/or development leads to Scrum Training. Upon their return they are expected to implement Scrum with their new training and knowledge. Sometimes this is driven by one of the groups sent to the training, but often it is an edict sent down from upper management. In either case this is setting the organization up for a rough transition to Agile.
Naypong – FreeDigitalPhotos.net
In general smooth agile transitions require more than an internal employee bringing info in from a two-day course. Support is needed from every level of the organization to make things work. Involvement is needed from everyone who will be working on the project teams. Different roles need different training to succeed with their new process.
Sending someone to training is a good start to the transition. A better start would be to send an entire team. This shouldn’t be a team of project managers, but the pilot team making the initial switch to the agile method of choice. This prepares the pilot team for success.
When the team returns they should meet with their management support. Two important things happen here. On one side management can communicate the hopes they had in starting this process. The other side is that the team can communicate what they expect to see happen in the first six months. This doesn’t have to be a confrontational time. Management saw some possible value in this to begin with or they wouldn’t have sent the team off. Bringing in an outside consultant can help keep everyone on track. The team is new to the whole thing, but should know enough from training to set some initial expectations for management. Chances are the team will not be able to transform as radically as management initially thought. On the flip side they should be able to promise greater transparency into what is happening during the transition than management expected.
With an entire team trained and proper expectations set between the team and management the actual transition can start. In a perfect world the team is working on a project that requires nothing from other teams which may impact the new processes they are putting in place. In reality they will likely be interfacing with teams that are not agile and not working to get there. This is where the team all being trained in agile values and principles can be more valuable than the specific method training they have received. Most of the current popular agile methodologies do not deal much with interfacing outside of the team. They tend to assume the team itself will be doing everything from start to finish with no reliance on the outside.
Even with these pieces in place it’s not guaranteed that the transition will be smooth. In fact, real-world evidence is showing that the transitions are almost always rough. By getting everyone trained, on-board, and supported that roughness can be smoothed out. Bringing in outside help is another way to help smooth out the rough spots that are tough to see from within.
This is hard for me to say. I like to solve problems. Most people reading this also like to solve problems. It’s in our blood to fix what’s broken, improve what’s inefficient. It can also be a mistake.
meepoohfoto – FreeDigitalPhotos.net
I’ve talked about this before. At the start of the Back to the Basics series I posted about Tensions to Manage. I’ve thought about this topic more lately as I’ve read about the shift in attitudes towards estimation. The desire of strategic decision makers for estimates is a tension at odds with the desire for the Agile Team to concentrate on the now. The solution doesn’t lie in eliminating all estimates. Likewise the solution doesn’t lie in forcing the team to do detailed estimates for everything. The solution is to manage the tension, not give a final answer.
These situations are common in an Agile transition, especially in the early days. To maintain our sanity as coaches we need to realize that not all problems need to be solved immediately.
