Author: Brandon Pearman

The views expressed here are mine alone and do not reflect the view of my employer.

"AGILE IS DEAD" has been headlines for quite some time now and there has been NO dramatic improvement on it. The cause is simple, Scrum is a money making racket which corporations eat up. The solution is for developers to take back control of their own processes. Experts in other industries know their craft and they know how best to execute. Software developers on the other hand get told how to do their work by so called "masters" and managers which have no clue how software works. Imagine if doctors needed to be told by a manager which is unqualified in medicine, on how to conduct their work. The Manifesto for Agile Software Development was created by developers for developers. So let's take look at what the manifesto for agile software development really meant.

There are some important agile principles which follow this value:

  • "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
  • "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
  • "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
  • "The best architectures, requirements, and designs emerge from self-organizing teams."

Important points to define:

  • Individuals definition: "a single human being"
  • Interactions definition: "communication or direct involvement with someone or something"
  • Processes definition: "a series of actions or steps taken in order to achieve a particular end."
  • Tools definition: "a thing used to help perform a job". In our context there is a more specific definition "a piece of software that carries out a particular function, typically creating or modifying another program"

Based on these definitions we can make some important assertions:

  • By definition scrum ceremonies ARE processes.
  • Tools are anything you use on the job including IDEs, git, excel, communication apps and story management software like jira
  • Tools also include "creating or modifying another program" like packages, databases, etc.
  • Individuals are humans with emotions, and emotions are unpredictable to a degree. For example people sometimes feels down for no apparent reason.
  • Individuals need to interact with tools to get the job done.
  • Individuals need to interact with other individuals to get the job done.
  • Processes directly affect all interactions (with people and tools).
  • A team is a collection of individuals which interact with one another.

How to apply this knowledge:

  • Allow processes to change to suit an individual, and their interactions with tools and others individuals:
    1. For the highest degree of agility teams must have full control over their processes and NOT management and NOT scrum masters
    2. Teams should consistently do what they need when they need. eg do small retros, reviews, plannings, catchups, etc as it's needed, so if an individual has an issue to discuss, do it now and don't wait two weeks for retro.
  • Allow tools to change to suit an individual, and their interactions with tools and other individuals:
    1. For the highest degree of agility teams must have full control over their tools, and be given a range of options and maybe even a budget. eg allow individuals to use any IDE or git GUI they want as long as they can manage their budget for it.
  • Consider an individual's highs and lows:
    1. Do not over work individuals. ie little to no overtime and reasonable deadlines.
    2. Recognize that an individuals motivation, energy and needs may fluctuate for no apparent reason so don't expect 100% all the time.
  • Treat individuals as individuals (Embrace differences)
    1. Trust is key.
    2. Cater special work processes and tools if needed. eg highly introverted specialized devs get a quite spot to work on specific tasks only.
    3. Protect each individuals rights, reputation, emotions, needs and wants. eg don't allow others to speak down to them.
    4. Involve and respect every individual eg get everyones input and thoughts on a topic and talk through it. (although this is not always possible try not override others with authority but instead try get them to see the "right way").
    5. Try find what motivates an individual and put them in that space as much as possible.

In conclusion

Processes which guide the team, as well as, tools which help developers work faster are important but neither will make a great team out of poor developers which don't communicate.

Don't think if you get the latest greatest IDE and trainers to come teach some new buzz word process, that the dev team will be great. The tools and processes will help but the core issue of the individuals and their interactions needs to be addressed.

Build a strong team first and then let them be part of building the environment that they are going to work in.

There are some important agile principles which follow this value:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Working software is the primary measure of progress.

Important points to define:

  • Working definition: "functioning or able to function."
  • Software definition: "programs and other operating information used by a computer."
  • Documentation definition: "material that provides official information or evidence or that serves as a record."
  • Comprehensive definition: "including or dealing with all or nearly all elements or aspects of something."
  • Customer definition: "a person who buys goods or services from a shop or business."

Based on these definitions we can make some important assertions:

  • By definition working software does not refer to the use of the software by the end user of the customer.
  • Documentation does not have to be text.
  • Documentation is not only explanations but also evidence and records.
  • Customers are the people paying for you to produce the software.
  • Users are people who use the software, which may be customers of your customer.

How to apply this knowledge:

  • Report on working software not story points:
    1. If story points are your primary measure of progress, it is easy for a development team to get nothing done.
    2. Working software matters to the customer, not points.
  • Do small iterations of working software to obtain regular feedback:
    1. Feedback may come from the user of the software or it may come from your customer. However, feature development is decided on by the customer, not the user.
    2. The goal is to satisfy the customer not the necessarily user so even if the software is incomplete and cannot be deployed, you can still demo a working feature to the customer.
  • Document via code where possible:
    1. Code can provide information, evidence and records, especially through test cases, configuration, naming.

In conclusion

Many companies consider "working software" to be working when its deployed to prod. While that approach works in many instances, it does not in many others. Definition of done depends on the task at hand, and if you create a blanket rule for everything then you are no longer agile. Remember the manifesto for agile software development does not define a "definition of done" not does it define work software as deployed to prod.

The main focus is produce working software in which the customer deems valuable for their specific case.

There are some important agile principles which follow this value:

  • Business people and developers must work together daily throughout the project.
  • Simplicity--the art of maximizing the amount of work not done--is essential.

Important points to define:

  • Customer definition: "a person who buys goods or services from a shop or business."
  • Collaboration definition: "the action of working with someone to produce something."
  • Contract definition: "a written or spoken agreement."
  • Negotiation definition: "discussion aimed at reaching an agreement."

Based on these definitions we can make some important assertions:

  • Customers are the people paying for you to produce the software.
  • Users are people who use the software, which may be customers of your customer. If I hire a development team to produce software, they must satisfy what I want out of the product. ie it is not their job to research the end user, that is my job as a business owner (and hire experts which do the research on the end user).
  • Collaboration and Negotiation requires discussion but the objective is different.
  • Collaboration does not require a set agreement and thereby produces agility on how to handle matter in the future.

How to apply this knowledge:

  • Consistently communicate progress and plans with your customer:
    1. By obtaining regular feedback the customer will be able to keep you on the right track, thereby reducing unnecessary work.
  • Have the ability to immediatly access a customer in order to keep work on the right track:
    1. Often the customer may not be available and thats where there can be representatives of the customer like a Product Owner
  • Always attempt to work together to find an optimal solution instead of pointing to a preset agreement:
    1. Have an open mind to a difference in opinion, and discuss it.
    2. Stories and sprints should NOT be mini contracts/agreements because every sprint becomes a negotiation instead of consistent collaboration with your customer.
    3. Developers should never reject work because it was not agreed upon, eg "I did not commit to that for this sprint" or "That is out of scope" or "The ticket does not say that"
  • Appreciate that different people think different and have different knowledge to bring to the table:
    1. Try obtain a diverse pool of ideas from different experts in different fields.
    2. Do not horde or dominate the development process. Allow non-tech people to get involved
    3. Explain things to non-tech in a simple way so that they can understand and input ideas.

In conclusion

Customer collaboration is all about keeping in contact and having open sharing interactions.

There are some important agile principles which follow this value:

  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Continuous attention to technical excellence and good design enhances agility.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Important points to define:

  • Responding to change definition: "do something as a reaction to someone or something" when that something has "become different"
  • Following a plan definition: "act according to" "a detailed proposal for doing or achieving something."

Based on these definitions we can make some important assertions:

  • In this sensentce, following a plan suggests ignoring the current situation.
  • In this sensentce, responding to change suggests that the plan did not foresee the current situation.
  • If a plan has foreseen an issue, then the plan can be followed.

How to apply this knowledge:

  • Plans should not be too specific and should cater for change:
    1. If plans are kept general and broad it is easy to adapt to new circumstances, without throwing out the plans entirely.
    2. If unknown change is expected in the plans, then the plans will be flexible enough to change and adapt.
  • Every step should include small iterations with regular feedback:
    1. By continuously reassessing the situtation it is possible to adapt the changes. eg think how often a thermastate should check the room temperature? once every minute or once every week?
    2. Reassess plans, processes, tools, designs, progress, interactions, skills, individuals, management, etc.

In conclusion

Responding to change requires consistent feedback ie how do you know to respond if you never noticed any change. Don't scrap planning but instead replan if and when needed.

If you do nothing else but stick to the following points, you will be able to be agile:

  1. Assess needs/problems as a team
  2. Do a small piece of work on the solution as a team
  3. Get feedback on whats done so far as a team
  4. Circle back to step 1

NOTE:

So don't confuse scrum with agile. Scrum is one way in which people try to be agile, hence agile is more important than scrum. If scrum getting in the way of being agile, then dump it.

Sources from agile manifesto signatories

Other Sources

If you look further you will find a lot more content on the topic