We’ve all been there. Here in the Northern US it happens like this. It’s the dead of winter. The days have been getting shorter and darker. The weather has been increasingly trapping us inside while simultaneously making our daily commute longer than ever. January first approaches and we make some resolutions, providing focus and hope. We work hard towards these new goals. We see some positive change. Progress is made and it makes us feel good. Then something happens.
anankkml – FreeDigitalPhotos.net
Sometime in late February or early March is when we tend to first notice it. We’ve lost momentum. Progress has stalled, and we aren’t really sure when it happened. We might have lost the initial progress. In some cases things have slid even further back then when they started. Most of the time by May it’s as if nothing ever happened.
Many Agile transformations are the same way. They start strong. Everyone has really good intentions. A couple of process changes are made. Some benefit is seen. Some resistance is met with facets of change that are uncomfortable. Concessions get made. The result is little change, minimal benefit, and stalled change initiatives.
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.
Scrum states that the right size for a development team is 3-9 people. I have seen that when teams are larger than this they tend to break themselves to smaller sub-teams. This lowers the risk of attempting Agile with large teams, and if managed properly can make it easier by effectively replacing the larger team with the sub-teams officially.
patrisyu – FreeDigitalPhotos.net
When teams are smaller than this it may seem nearly impossible to properly “Do Agile.” An important thing to remember right off the bat is that Agile Is Not Scrum. It’s also worth remembering that Agile is a journey.
Take Pair Programming for example. It either is or is not happening. There are different ways of doing it. It can be tweaked a little over time. At the end of the day though, you either are or aren’t Pair Programming and if your process doesn’t change neither does that fact.
Agile is not like that. There is no end state where you can say you are Agile. If you think you’re at such an end state you have succeeded in no longer being Agile. Being Agile, or working with Agility as it were, requires the ability to change. Being Agile means one will constantly be open to inspection and adaptation. A static end state is completely at odds with this concept.
I spend a decent amount of time pointing out that every Agile Journey will look at least a little different. I appreciate frameworks such as Scrum. Having a defined process to follow generally makes the initial start of a transition much easier.
In the last post I pointed out that change has to start somewhere. In fact, I would state there is no Agile Journey without change. Being Agile is deeply rooted in responding to change. It’s one of the main values from the value pairs. An Agile journey with no change is as useful as a cancelled cruise is fun.
We all played at it when we were younger. “If you were stuck on a deserted island and could only bring one person/item/food what would it be? As we prepare to enter the new year I thought I would ask a similar question. If you has to start down the path of Agility with only one process what would it be? This isn’t about what one value pair or principle you would follow. As an Agilist I hope that your preferred process does line up with one, but that’s not the point. All change has to start with something. If you were only allowed to do one change at the outset, what would that change be?
Maybe you would start with iterations in hopes of rapidly delivering value to your customer. Perhaps your first order of business would be to change your teams so that developers, testers, and business representatives are working together on product teams instead of separately on functional teams. It may be time for you to bring your product team and your customer together for some direct interaction.
Whatever the single step you could take is you should move forward with it. Every team and situation is different, and as such there are multiple right answers for what one thing you should start with. As a coach or agile change agent you may have a favorite that you lean towards starting with. I’ll be back after the new year to talk about my preferred starting point and why. In the meantime, feel free to share your preferred starting point and why.
The Agile Manifesto has important things to say throughout for any time of year. As Agilists we should seek to embody it whenever we can. We should allow it to guide our thinking, decisions, and actions at work.
While the Values are at the core of the manifesto, the 12 principles are important to know as well. This time of year is a good time to focus on one part in particular, sustainable pace.
The actual text from Agilemanifesto.org is:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Because I believe Agile principles and practices can apply outside of software development I like to think of sustainable pace versus sustainable development. They should be thought of as having the same meaning.
Classic software development is thought of having a “death march” at the end. This has been true for some teams in the past, but is not a given. The idea of the march is that a large amount of stuff is butting up against a final deadline and has to be working no matter what. The causes are varied and not relevant to this post, but that it happens is.
In Agile we make small bits at a time. There can be no death march because there is no large deliverable to slowly creep to a long away deadline. There is a deadline coming soon, and a small amount of stuff to be done by then. Right after that will be another near-term deadline with a small amount of stuff to be done by then. If there is a “mini death march” as we come up on one deadline, less stuff is promised for the next deadline.
One advantage is sustainability. By eliminating the death march we save our people and allow them to perform better more often. Without a death march looming over them the people on the tea will have no problem continuing to deliver.
During the holidays that need for sustainability becomes stronger. People are under stress from outside influences. Their friends and family are demanding a little more time than they normally would. Their ability to commit at work may be impacted. An Agile mindset allows us to continually adjust our commitment and maintain sustainability for every member of the team.
Do you account for outside factors as you plan future iterations? How could you start?
Almost every time you hear about how to become more Agile automated testing comes up as a must do. The natural assumption might be that automated testing is required for a process to be Agile. If a team doesn’t use automation they feel they cannot be Agile, so why bother trying?
I have read the Agile Manifesto many times. Of course the value statements wouldn’t have anything this specific. I’ve read the 12 principles many times as well. I have never seen where the manifesto or the underlying principles require automation in any form.
The basic goal of Agile is to deliver better value more quickly. The Agile Manifesto clarifies that the way to do this lies with people working together. The success criteria for any given project/product, from an Agile perspective, is related to value delivery.
Why then do we need to use specific processes and methods to be considered “Agile”? Truthfully the answer is “We don’t.” The better answer is “To learn.” We use specific process to learn the Agile mindset. We follow a pattern to learn why the pattern exists. Essentially, we use these processes and methods to learn the fundamentals of Agile. We use them to truly internalize the Agile Manifesto. They are the Shu in Shu Ha Ri, the first stages of the Dreyfus Model, or stage one of The Four Stages of Competence. But then, we realize as we teach and coach this that questions wasn’t “Why are we learning Agile with these methods,” the question was “Why are we bothering with Agile instead of just doing our jobs?”
Trust. If you read about Agile you will see this word. If you read about implementing Agile you will see it even more.
There’s a good reason for this. Trust is important to the success of Agile. Without trust from the organization a team will not function at the level expected.
Thing is, there’s a piece of this that is missing from almost every discussion of Agile I read. The team has to trust the organization.
We’ve all heard it before, but what does it mean, “Permission to Fail?” How about its cousins, “Fail Fast” or “Failure IS an Option?”
The idea isn’t to promote failure. Nobody, from team members to stakeholders, wants that. The idea is to create an environment open to change.
An Agile team should have enough power to try things that won’t necessarily work. This is not to say every Agile team is a prototype lab. In fact, the majority of what a mature Agile team tries will likely result in more value delivered to the client. Even a relatively new Agile team should see more successes than failures. These “things” the Agile team is trying can range from specifics of how to implement a feature for a user story to a new bonus structure more befitting of the team.
There are two basic types of failure that we consider when we think of these phrases. One is a failure of delivery. The new component didn’t work with the rest of the application. The other is a failure of process. Adding a mid-iteration PO demo resulted in too much confusion.
Delivery failures are the most visible. They directly affect the delivery of completed items to the product owner. Something happened and it prevented stories from meeting the definition of done by the end of the iteration. It could come from an attempt at using an unfamiliar back-end platform for new functionality. Perhaps a new type of interface is being introduced to user. Preventing these problems is important, but so is allowing them.
One method of preventing delivery failures is the concept of the spike. Basically, instead of trying a new thing out on a promised user story and hoping for the best an extra task is created. It usually runs at least an iteration before the relevant user story. While it will have no deliverable to the product owner it may result in a demo to the product owner. It is used as a proof of concept for something that will be used in addressing later stories. The permission to fail is that the spike might result in an answer of “this just didn’t work.” As a product owner it is important to realize that while this may not be a deliverable result it is still a valuable result.
A failure of process is both easier and harder to deal with. A high performing Agile team will eventually want to do something that doesn’t conform to the rules of whatever process they started with. For instance, they may want to eliminate the daily stand-up after implementing Scrum to start their Agile journey. The idea and reasoning should come up in the retrospective. This is a move that Scrum will not allow, but Agile will. It needs to be a time-boxed experiment that runs for a bit and then is reviewed. While many examples exist of this being a bad move for Agile teams, it has also worked for some.
Process changes need management buy-in. To prevent failures here the team needs to own the process with management supporting it. The team will find ways to improve their work. Management needs to allow changes where possible and valid explanations of why not when they cannot. If the team understand why a process change cannot happen they will be more likely to find another way to address the problem then if they just get a no.
In trying to be Agile we need to be open to change. Inspecting and adapting often. When change happens we never know 100% what the outcome will be. The classic risk-averse approach to project management often stymies change efforts in new Agile teams. All we are saying by providing permission to fail is that more risk is acceptable than previously thought. Without accepting that risk the rewards of positive change cannot be realized. If attempts at positive change are not allowed we are not Agile.
