I have been a software developer since June 2008. Before that I spent almost 5 years working my way from part-time computer support to Systems/Network Administrator & IT Team Lead of a 500 person multiple campus company. Before that I did 2 years as a phone support technician. With over 12 years of IT industry experience spread across both system administration and software development I see IT in a broader scope than most.
Now I am becoming something more. I am an Agilist. I am moving on to project management. I am pushing positive change within my team, group, and company. I am looking to provide the best solutions for delivering the most value to organizations in the shortest practical time. I believe that even as I move from implementing Agile to teaching Agile to others I will never be done learning it.
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.
Every attempt at transition can have issues. Some issues are fairly common regardless of who attempts the transition. No matter who tries to cross the Sahara there will be a lack of water available during the trip. These common issues are often called red flags.
Every desert crossing attempt is unique. The people and methods involved vary. Some may be making the trip over the course of week, others in just a few hours. In each of these circumstances the best way to address the lack of available water is very different.
In Agile transitions there are also red flags. Just as with crossing the desert each Agile implementation is different. As such there is not a proper way to address every issue every time. The more similar organisations are the more similar the solutions may be, but even that is not a given. Today we are looking at the Agile red flag of a Powerless Product Owner.
Agile transformations affect the entire organization. Successful transformations require participation from everyone in the organization. The teams have to be willing to try new ways of working. Management needs to be willing to try new ways of determining success. Executives need to be willing to try new ways of measuring value. It can even be more specific with Human Resources needing to find new ways to structure compensation and legal finding new ways to structure contracts.
Failed and struggling Agile implementations often leave someone out. Sometimes it is a bottom up process struggling with blockers or legacy process. Other times it may be a top down initiative fighting teams that are against changing their process. The problems can even be external where a client will not, or cannot, accept a new contract structure to support Agile. In any case the more people on board, the greater the probability of success.
As I mentioned in my last post I would like to create training. For some reason I feel like Estimation is a decent place to start. I think a one hour online video training session is something I could probably produce. I would also like a longer interactive one of 2-3 hours. I think that is long enough for estimation.
It isn’t long enough for Agile though. The training will come with the assumption that the attendees understand the Agile concept of making decisions and commitments as late as responsible. This will be briefly addressed, but it will not be gone over in-depth. Concepts I hope to cover include reasons for estimation, value versus cost of estimation, when to estimate, estimation techniques, and estimation red flags. The target audience will be teams new to group estimation, new scrum masters, and project managers new to Agile methodologies.
It has been a little over a year since I launched this blog, and approximately 6 months since my last blog retrospective. I have been reflecting in the interim, but have not taken any time to specifically reflect and adjust.
In the last six months I have kicked off a new style of post called Red Flags. I also have made an effort to have some type of image, preferably relevant, for every post. I also have finished out the initial Back to the Basics post series talking about the value pairs from the Agile Manifesto.
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?”
Agile, adjective. able to move quickly and easily. The final value pair focuses on the “Agile” part of Agile Software Development.
Responding to Change
over
Following a Plan
If we cannot evolve our plan over time then we are not Agile. This value is not about constantly changing for the sake of change though. Agile practices value the ability to change as new information is discovered.
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.
One idea that confuses people when moving to Agile is the concept of the cross-functional team. The idea is that the team has all the skills necessary to move every item from pending to done by the end of the iteration. The wording is that the team is “self-directing and cross-functional.” Many people read that and start to worry about having a team of generalists that can accomplish any given task at any moment.
This can lead to very unsatisfied team members. Imagine this same situation in a restaurant. The head chef would possibly bring guests from the front door to a table while the bartender may have to make side dishes. Not only would this result in sub-par products, the people in question would likely look for new jobs.
I have good news. People do not need to seek new jobs because this is not the intent of cross-functional Teams.
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.
