Tag: Kanban

Agile Manifesto – Working software over comprehensive documentation

Working software over documentation

Just for the record documentation has its place, especially early on during say version 1 of an application, but it’s no substitute for software that actually works and thus fulfills the requirements. The reason I say documentation has its place in the early stages of an application, is that is when it is most accurate, and over time it becomes less and less accurate as developers make changes and the documentation remains the same. I can hear the screaming now; the developers are supposed to update the documentation as they make changes aren’t they? Sure, in an ideal world, but you and I know this just isn’t true.

The authors of the Agile Manifesto were just trying to emphasize that the most important thing when developing software is that it actually works. I have led many projects that required extensive documentation, only to find out later that no one was reading it or could even  find it. In fact most of the time it was the high level architectural diagrams that had the most value and could stand the test of time, at least time that is measured in months. Being agile in software development means being able to frequently release new functionality; with the idea being that delays in releasing working software only postpone value being delivered. If you wait for extensive documentation to be developed before releasing software you will always be late to the party.

I often see the conflict come into play when an organization has three separate entities involved in the creation and release of software. These organizations are Q/A Testing, Developers, and Business Analysts, with the most conflict occurring between the Testing organization and the Developers. The more deep rooted problem is a lack of agility and lack of automated testing tools. You probably encountered some of this in the form of “You need to finish all the functionality before promoting it to the Q/A or Staging environment, so I don’t have to retest everything”. Let’s be real with each other, a lot of organizations think they are doing agile development, when all they are doing is wrapping Scrum around their waterfall processes.

This is all about what is most valuable, and the point of software development is to create working software that meets the needs of the organization.

I would love to hear your feedback.

Advertisement

Agile Manifesto – Individuals and interactions over processes and tools

The first statement in the Agile Manifesto is “Individuals and interactions over processes and tools“.

Why is it more important to value individuals and interactions over processes and tools?

    • You can have the most wonderful process in the world, but if you don’t have the talent on your team; you are in big trouble. A rigorous process won’t save you if you don’t focus on individuals making high quality contributions.
    • Take interactions in the area of collaboration. Just because you have a daily scrum doesn’t mean you have high quality collaboration occurring. What if you have all the processes around communication in place, but the individuals on your team are constantly arguing with each other or worse undermining each other.
    • Agile processes require individuals to do the right thing and adapt to changing requirements and situations, versus just blindly follow some elaborate process. If you don’t invest in the individuals on your team, you may end up with a lot of disengaged team members and your burndown begins to flat line.

What I have seen in the past few years is an increasing focus on agile frameworks that have many processes, artifacts for everything, and one tool after another added to the stack. Let’s be honest a lot of the agile frameworks I see being used reflect a prescriptive a process as if they were lifted right from the Project Management Body Of Knowledge (PMBOK). In many organizations the amount of latitude given to the team is almost zero, and there is no such thing as a self managed team. I see adherence to process dominating what some people call agile frameworks; the hell with the results, instead it’s all about how many of the best practices you check off during a project review. Surely if you are following the best practices and using the most comprehensive tools you must be doing it right, well that’s the thinking behind it. Forget about the people, just follow the process and all will be well.

Listen, I’m not against using a good framework like Scrum or Kanban, or tools like Jira or Azure DevOps. In fact it is essential to have a framework that has some proven processes or ceremonies to utilize, but when you keep adding on additional processes and tools you begin to constrain the choices your team has at its disposal. You trade a self managed team , for adherence to a rigorous process. Ultimately you chip away at innovation, choice, and instead of focusing on the core work, you are focused on supporting some corporate metrics. Last but not least you begin to make all work equal as the administrative burden on the team increases and job satisfaction plummets.

The next installment of the Agile Manifesto will focus on “Working software over comprehensive documentation”. I would love to hear your comments, either supportive or not.

%d bloggers like this: