Tag: agile manifesto

Agile Manifesto – Customer collaboration over contract negotiation

Customer collaboration over contract negotiation

The third statement of what we value from the Agile Manifesto states:

Customer collaboration over contract negotiation

This is an interesting statement for me as I am a consultant and the basis for my engagements with customers starts with a contract, in my case a Statement of Work (SOW). While an SOW is the starting point it is often left fairly vague in some ways to allow for adaptation during the engagement. We do this purposely so that we can work with the customer to uncover the requirements that fit into the broader framework of deliverables.

It is clear to me that the authors of the Agile Manifesto felt that clearly collaborating with your customer was superior to using a contract as some kind of checklist. The project may become highly adversarial in the event that we spend our time fighting over items in the contract instead of making sure we are collaborating with our customers. There is nothing less agile than simply following a contract instead of being focused on delivering the right business outcomes.

I have been as guilty as the next person is thinking that the customer understood the contract in detail, and when we delivered to the letter of the contract we actually had issues. This became my fault by not collaborating with certain stakeholders to the degree I should have. In fact, I know a fair amount of customers who never even read the SOW, so thinking you can use that later to negotiate delivery is somewhat meaningless. On the other hand, I have worked with customers where they analyze every sentence, clearly using the contract as the source of truth for all deliverables. This is both painful for the project team and really not in the customer’s best interest.

So what’s the best thing to do during an engagement if you are to adhere to the agile tenant where collaboration is preferred over contract negotiation? My advice is to do the following:

  • The contract is a starting point for understanding high-level deliverables, maybe these deliverables become Epics in your backlog.
  • Let collaboration guide your team with the focus on creating business outcomes, instead of blindly producing what the contract outlines.
  • Instead of spending your time talking about what is in the contract, it is better to collaborate with the customer to show them that you will over-deliver and have their best interests at heart.

While this seems like such a simple statement that we value collaboration over contract negotiation, it speaks loudly to the real intent. In almost every engagement I’ve been a part of, requirements change as we learn more, and an agile team knows this and will use it to their advantage to produce something better than originally scoped out. Letting a contract dictate the total scope of the engagement and ultimately what is delivered in the end is not agile, but instead waterfall.

I would love to read your feedback on this subject.

 

 

Advertisement

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.

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.

The Agile Manifesto #1

Anyone who has been involved with agile software development or project management would have likely at one time read the Agile Manifesto. I would like to dissect these somewhat simple yet powerful precepts and discuss whether we have lost sight of these principals, since it was written way back in February 2001, more than 19 years ago. In this post I will focus more on the historical perspective of the Agile Manifesto; where in future posts we will delve into each of the principals and our adherence or lack of adherence today. The other question we will explore is the Agile Manifesto still relevant?

The agile manifesto states:

“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.”

The authors of the Agile Manifesto include

    • Kent Beck
    • Mike Beedle
    • Arie van Bennekum
    • Alistair Cockburn
    • Ward Cunningham
    • Martin Fowler
    • James Grenning
    • Jim Highsmith
    • Andrew Hunt
    • Ron Jeffries
    • Jon Kern
    • Brian Marick
    • Robert C. Martin
    • Steve Mellor
    • Ken Schwaber
    • Jeff Sutherland
    • Dave Thomas

This group of collaborators was actually the who’s who of software development at the time representing various frameworks including Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and several others. When you think about it, this was somewhat amazing that they could agree on a set of principles that would become what we consider agile today. In addition to the Agile Manifesto the group created 12 Principles for Agile Software development:

    1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    4. Business people and developers must work together daily throughout the project.
    5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    7. Working software is the primary measure of progress.
    8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    9. Continuous attention to technical excellence and good design enhances agility.
    10. Simplicity–the art of maximizing the amount of work not done–is essential.
    11. The best architectures, requirements, and designs emerge from self-organizing teams.
    12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I hope this was a good refresher on the Agile Manifesto. In the past I would start with this when teaching a class on Scrum to set the stage for what is possible. My next post will go into detail on the principles advocated by the Agile Manifesto.

Reference:

https://agilemanifesto.org/

 

 

%d bloggers like this: