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.
Estimation is an important part of planning but estimation is useful outside of planning, helping decision-makers and line workers both.
Estimation in an Agile setting should be done as a relative function: Option A is bigger, Option B is faster, etc. (If you disagree or don’t understand why let me know and we’ll have a chat, maybe even create a new blog post.)
Estimation outside of planning is a tool for decision-making. I know, isn’t that just planning? Not exactly.
Classic planning is all about a specific timeline and sticking to it as closely as possible through as much effort as possible. All risk possible has been assessed upfront and now is the time to act. Agile planning accepts changing conditions and addresses risk as it arises.
How does this relate to estimation?
In classic planning, a large amount of effort is spent getting the most accurate estimates possible at the outset, and those estimates are often used as gospel when controlling change later on. In agile planning, just enough estimation is done to make the next decision that needs to be made.
This doesn’t mean agile teams have no concept of how long the entire project may take. It does mean instead of promising they can finish in 8 months, 2 weeks, and 3 days they promise they can finish in 6-12 months. The most important tasks are ordered based on expected value and they are given a deep-er level of estimation. As the team moves forward, value is constantly revisited, task importance is allowed to shift, and only the most important tasks are given enough estimation effort to know when they’ll be done.
Of course, this is an oversimplification. Details belong in a dedicated post, and I’ll do one of those soon.
Estimation is also an important tool outside of planning. When someone from DevOps needs to set up load tests, they’ll estimate the expected load. This isn’t an estimate needed for project planning, but for testing. A developer may estimate some values for an algorithm they are creating to solve a business need.
Estimation is useful on a personal level for everything from planning to easing the cognitive load of making lunch. Estimating what you can get done in a day will allow you to leave room on your schedule for unexpected interruptions. Estimating how much sauce you’re adding to your chili for the team slow cooker partyc an get you out the door faster than exactly measuring it.
Estimation is something we all do, all the time. It’s easier than exact measurement much of the time. Unfortunately, we are bad at it. That, however, is a topic for another day.
Want someone to help you evaluate your current planning or estimation practices? Contact me today for a free consultation. We’ll discover your need and see if we are a fit to work together.
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.
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.
There is a danger in taking the separation of work and home too far. If people are putting on a mask at work and not bringing any part of their true self, then they will almost never truly become part of the team.
We’ve talked about this before. Turning a group into a team takes more than just giving them an activity together though. Each person in the group needs to be willing. More importantly, they need to feel safe enough to bring themselves to work.
I’ve been guilty of this in the past. My time in the Navy is a great example. Who I was on base during those four years was very different than who I was on leave. The team on the submarine never got to know me, even though we’d spend weeks stuck together underwater with little to no interaction outside of the boat. Sure, pieces would sneak through from time to time, but I never delivered my true self.
In another job, I not only allowed myself into the workplace, but I was also friends with some of my coworkers outside the office. Invariably, every time I’ve been on this type of team it has been a better experience, at work and home.
While not coming into the office has its own set of problems, it also does something amazing. It brings the office to everybody’s homes. When working from home, people generally feel safer, and more willing to let themselves, their true selves, into work. This naturally increases trust in the group, either bringing them closer to being a team or closer to becoming a high-performing team.
If your teams are struggling to work together I can help. Whether it’s a struggle due to working remotely, or a long-standing effort to move from group to high-performing team that has stalled get in touch and we’ll set up a 30-60 minute discussion on your needs and how I may, or may not, be able to meet them.
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.
The idea of reaching performing is not fantasy, the idea of reaching it and being set for the long haul is. The problem is that constant of change. Whenever a team undergoes change it is likely to slip back to a prior stage in the model.
The obvious sources of change are new team members, losing team members, and leadership changes. There are other, more subtle places it comes from though. For instance, one of the team members’ parents move into town, or a spouse loses a job. It doesn’t have to be big life events either. A child making a traveling sports team can really upset a summer schedule and affect work. In some cases, something as simple as a new snack machine vendor could have unforeseen consequences.
This isn’t a bash at Tuckman’s model. Truth is, it’s a very good one. Teams do go through stages, and when the project is temporary in nature a team can “finish” in a performing state. However, with today’s focus on product teams that go on for much longer than a development team may have in the past, there often isn’t a clear “end” in mind for a team when it is formed.
I like to approach the Tuckman model as more of a journey than a ladder. The team isn’t climbing its way to perfection, but rather on a journey of continuous improvement which is constantly adjusted. The destination guides the direction, but the focus needs to be on the journey and where the team is at. Every challenge the team hits doesn’t knock them back, it merely alters their path.
When people gather it’s called a group. You might see a group of people at the park, in the mall, or in an office building.
There’s nothing inherently wrong with a group. People naturally gather, even extreme introverts such as me get together with others at times.
A group can generally do more than an individual. Some things even require a group, such as sports.
Eventually, something happens though. For some things, a group isn’t enough. A group will reach limits. It will run into obstacles outside the abilities of a simple group. For highly complex situations something more is needed. The group needs to change, it needs to become a team.
Often the only thing that binds us to others at our job is having been hired at the same company. There are exceptions all over, some people work with family and some got jobs with friends. These are less common though, and even when someone gets a job with a friend or family member they generally find themselves surrounded by people they do not know.
Regardless of your hiring process, this means that at their heart people working together are nothing more than a group. None of us like to think of it that way though. We always think of our co-workers as part of our team. In fact, at Target everyone is considered a “Team Member” as opposed to an employee. Recruitment all over espouses the benefits of joining the team at company x.
How do you know if your group of employees is a team?
According to Merriam-Webster a team is “a number of people associated together in work or activity.” (https://www.merriam-webster.com/dictionary/team) By the book, a group turns into a team much more quickly than I suggest above.
However, consider a collection of people who gather every day. They each do a task that, when combined, outputs a single product. They do not talk to each other. Not one of them pays any heed to what another does. When they aren’t gathered in that space, they have nothing to do with each other and don’t even cross each other’s minds.
By the book, that’s a team. In my mind, they aren’t.
Agile practices promote the idea of creating high-performing teams. I’ve always felt the operative term here is “team” no “high-performing.” The next question is, how do you determine if you have a team or a group?
I contend a team not only has a common goal but that they also constantly strive to improve on achieving it – together. A team knows their whole lives affect their time together, and they strive to make their time working towards a goal better by connecting outside of that time.
If your team punches the clock and checks out, it may not be a team after all. You need to engage them, get them excited for what they’re doing together, and get them interested in working together. This can be as simple as hosting a quarterly game day. Let them spend half of a Friday every few months playing group games together instead of working. It can also be as elaborate as booking a group vacation for them, dropping them into a wilderness retreat for a week where they can get to know each other better. They come back with a shared experience that helps them relate to each other, and eases the tension on working together.
Wherever your team is on the spectrum of a group to a high-performing team a coach can help bring them to the next level. A coach from outside the organization can see things the organization has become blind to, garner trust the people may not have in the organization, and provide relevant experience from other environments. They can help a group discover what’s causing them to hold back from each other, even if they don’t yet realize they’re holding back. They can help a team realize a rut they’re in and provide ideas of alternates to break out of it. They can help a high-performing team communicate better with the rest of the organization.
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.
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.
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.
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.
