Agile (Capital A) is something that many/most software development teams are adopting, whether that is pure Agile, Safe, Scrum, Kanban, or some other thing that I don't know. The majority of the issues that I hear about surrounding Agile are having to do with forgetting the manifesto OR forgetting to be agile (lowercase a). So let's take a look at what can be done about these.

Agile Manifesto:

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

Working software 
	over comprehensive documentation

Customer collaboration 
	over contract negotiation

Responding to change 
	over following a plan

That is, while there is value in the items on the right, we value the items on the left more

Processes and tools are largely the way that management ensures that a team is on track. I regularly hear complaints about stories not being updated in the agile management software, or processes not being followed. I find that this largely means that we aren't interacting effectively. While individual empowerment is largely a pillar of agile, being a part of a team where you aren't the only one interacting with or planning the activies for a given product/application means that you must communicate effectively. In order to reduce your focus on processes and tools you have to get to a point where your team communicates well without the rigidness of those things.

Comprehensive documentation would be really nice in an ideal world. I personally work with fifteen applications which have been managed by a team that has completely turned over at least twice. There have been large blindspots in regard to the applciations' functionalities which is an ongoing process of remedying. But, even for the things that we have sufficient documentation there is an issue of being able to find it. Further as the team has turned over through the last decade, the code styles are a world away from consistent. The betterment of the team and the code has not come through writing large documents that explain everything, but instead through taking the time to gather and share knowledge as necessary. It has been my experience that if your organizational skills are lacking then the documentation will likely not be a fix for it. Making sure that we have testing suites that find issues and profiling systems to evaluate issues with runtime have been paramount in our moving forward.

Contract negotiations can be really helpful but will ultimately have details that are left out. This comes down to one of the fundamental issues with waterfall as a whole. You would take the contract that was poured over for weeks, and then you would take it with a bit of interpretation and make what you believed to be desired. Customer collaboration allows for us to ask the questions as we have them and not make assumptions that go unchecked until final delivery. Customer collaboration also means that iterative deliveries can be checked agaisnt assumptions that customers may have had without ever having specified them. You still wind up with an effective contract, but by letting that negotiation be ongoing collaboration rather than a pre-development meetings that produce a clean cut document you minimize the amount of work done on something that is not wanted.

Following a plan goes hand in hand with contract negotiation. Responding to change means that you are allowing for feedback that prevents excessive time waste in direction corrections.

Lowercase a agile

Going back to the bit about processes and tools, I believe that the problem comes down largely to things that are mostly minor details. Do you estimate story points by days of work or complexity of work? Do you assign multiple people to the same story or make a copy of the story for each person involved? You can go either way with these and several other decisions and have them be helpful to your team, but ultimately you should remember that if any part of the process or the tool are getting in the way of doing actual work then you need to evaluate how to remedy that.

My team lost its scrum master recently after his having been with the team for more than a year. Initially we believed that it would be disasterous as we have had difficulties with several parts of our process in the past (merging of two whole scrum teams, changing managers a couple of times, completely differing approaches to standup) and he was a large part of helping us to reign in those issues. But it's a really crazy thing. When we learned that we would not be getting a replacement of our scrum master we were forced to divy out his work. This brought about executions of different steps with different understandings and personal tendencies. And in this change we have become stronger. The people that were interested in the different processes were able to consider how they could better their part of the process instead of one person trying to figure out all of the things.

Scrum master activities hve been split up. Our manager takes over administration activities like scheduling meetings and mitigating external dependencies. Her vision as a manager gets us farther. A new junior dev runs our daily standups. He is now more engaged and knowledgable. A dev lead took over for backlog grooming and sprint planning. Suddenly defining done is a non-issue. I've picked up retrospectives. I began by asking each person for their input on 'done well', 'need to improve', and 'action items' which brings more feedback from more people. We collectively took on our Program Increment planning activities. Showing up without pre-planning enabled us to plan more effectively due to increased awareness. Our business team is more aware of our activities as we brought them into planning. Overall we are becoming increasingly efficient with our meeting time due to these changes.

Aside from just the changes that came with the loss of our scrum master, we figured out that the way we had been tracking support issues and Keep The Lights On (KTLO) activites was not providing adequate visibility, bandwidth, and pushback. We have since stopped tracking support activities as stories and instead opened a request queue for such things. We have reduced our velocity to better accommodate those activities, and we have separated out our bandwidth by onsite development, offshore development, and testing in order that we may better distribute/track our work in accordance with the people that will actually be performing it.

I don't offer the things that my team has done to give our example as perfection (far from it), but as growth. We have tramendously changed the way that we carry out agile practices and are becoming stronger for it. I, being transferred to the team more recently than most, have been finding several issues with our process and questioning everyone as to why we do things the way that we do. In the process I am able to learn the good and bad reasons that we operate as we do, and I've been able to offer thoughts as to how we might better our processes. Just opening this discussion (because I'm quite open with my thoughts) has led to further discussion of streamlining our activities. There were initially a handful of meetings where we devolved into verbal sparring matches and the majority of people were quite upset. After we got everything off of our collective chest then we were able to begin seeing things from the other perspectives, function as a more cohesive team, and find value in our tramendous diversity of skills and experience.