There is something I heard at work the other day that I wanted to discuss. In my many years in various development departments I have often heard about “Feature factories”, or how your process is like building a bridge or something similar.

It seems as though we like to make comparisons to manufacturing for some reason. Maybe this is because that is where many managers came from in the past. Another possible explanation is because software engineers need to explain things to managers who have never written software. Whatever the reason is there seems to be a general misunderstanding around writing software, and that it is in fact very different to manufacturing.The downside is that, in my opinion, this has consequences for developers.

When we explain everything in a manner related to manufacturing we make it sound as though writing software is something that can be done once and then repeated easily. This is often not the case. When we are given a problem to solve in software, there are often differences to what we have done in the past. These subtle differences mean that we need to treat the problem as being new and different. Sure some components can be re-used and we can use various frameworks. Still it is quite different to manufacturing.

So what is a better analogy for writing software? I think that something like writing a book or doing a scientific experiments is closer to the mark. I think that experimentation is a better analogy than manufacturing. Writing a book is not a repeatable thing, each one is a bit different. The process might involve steps like brainstorming, create a rough draft and continue to refine it, etc. In the same way science is about trying things until you find what works. Software is like that, a little different each and every time.

Ok so it’s about experimentation, but why is that different to manufacturing? It is different because it is like the design phase of making something new each time. You wouldn’t want people to experiment with how to build a road each time they have to build a new road, you wouldn’t want every possible design of bridge built one after another in the same place to find the best fit (Well you’d have to knock the previous iteration down between each build as well so that’s kinda bad and wasteful too). Building something, even something complex like a car, is something we understand very well. It is the design that is a little different each time. Writing software is like that design phase, not the manufacturing phase.

When we think of car production lines we aren’t thinking of the design phase but the production phase. That is analogous to making a new copy of the same software. If you remember the glorious times of software on CDs and DVDs, then the production line is the act of producing the copies of the software to be sold by writing the CDs/DVDs. The act of writing software is like designing a new model of car.

In summary

When we talk to management and they make the mistake of using a poor analogy, we should stress the difference and that we cannot have a team of developers working like a “Feature factory” similar to how a car assembly line works. We are more like car designers or scientists trying to find the right solution to a new problem. The target is always in motion and we will make “Mistakes” and learn along the way.

We’ve looked at the manifesto for agile software development. There are also 12 principles being the manifesto. As we are about to embark on a journey of exploration of some of the “agile” methodologies, it might be instructive to start by reviewing these principles and to try and group them a little bit.

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 maximising 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.

When we look at the principles only a few major categories jump out at me. What do you see? The categories are that I see are:

• People focused
• Software focused
• Process focused

Naturally we would expect the principles behind the “Manifesto for agile software development” to be principally focused on software and processes wouldn’t we? What is interesting is that I wouldn’t categorise them that way. What might seem reasonable on the surface (Process and software focus) doesn’t seem to be the case. Allow me to split them up a bit by rearranging them the way I see them (For brevity I will only write out the part that stands out to me):

People focused

1. Principle 1 – Customer satisfaction.
2. Principle 2 – Changing requirements for customer advantage.
3. Principle 4 – Developers and business people working together daily.
4. Principle 5 – Teams of motivated individuals.
5. Principle 6 – Face-to-face communication.
6. Principle 8 – People able to maintain a constant pace pace.
7. Principle 11 – Self-organising teams.

Software focused

1. Principle 3 – Frequent delivery of software.
2. Principle 7 – Working software as progress.
3. Principle 9 – Focus on technical excellence.

Process focused

1. Principle 10 – Reduce work done.
2. Principle 12 – Inspect and adapt.

Whilst it would be easy to a put a few of the principles in more than one category, I put them in the category where I think their focus lies. When we do this we see that 7 of 12 principles focus mostly on people, only 3 have a mainly software focus and just 2 are primarily process focused. Surprising? I don’t think so. People do the work and generally for other people. A focus on people is important. We also see a similar focus on people in the values of the manifesto.

This also throws up an interesting question. If you are struggling to adopt agile ways of working, maybe you could ask yourself where your focus is. Are you focused on people? I’ve seen too many companies and teams try and become more agile by focusing on process and methodologies. It is almost like many people think that you can just copy another team or just do scrum and magically become agile.

In conclusion
If you focus on process and ignore the people then you will likely struggle to become more agile. Int has been my observation, at the various companies that I have worked at, that most “Agile transformations” focus on process over people. Companies that think that introducing some frameworks will magically make them agile often make little progress and little headway. The companies that focus on the people are much more likely to succeed.

There are many methods and methodologies that fall under the umbrella of “Agile”, some of them have become very closely associated with agility, and even seem to be treated synonymously with “Agile”. Yet as we have seen, the manifesto for agile software development consists of a few short statements centred around 4 values statements. There are also 12 principles that we will look at over time on this blog. Whilst those principles are important, they are less relevant to the point I want to make here. Given what the manifesto for agile software development says, how do we get statements like “Agile says…”, “Agile user stories” or “Agile meetings”? In my opinion the answer to that lies in what I have chosen to name “My Agile”. As in people who, have probably chosen to, focus on a single method or methodology.

There seem to be more and more people who conflate their chosen, or favourite, method(ology), with the only way to “Do Agile”. This makes no sense because you cannot “Do Agile”. Agility, based on the manifesto, is a few values and some statements that we treat as facts (The principles). You cannot “Do” values and principles, they are true or they are not true. Values and principles guide (Or allow us to evaluate) our behaviours and mindset. They guide how we should do things rather than being what we do. Consider the following “Do value individuals and interactions over processes and tools”. That sentence makes no sense. However, if we ask people “How do we know that you’ve chosen a way of working that values individuals and interactions over processes and tools?” Then that makes sense, and we can answer it. A good test for if “Agile says…” makes sense is to replace the word “Agile” with how we want to work. For example we might want to work in a manner as to be flexible or adaptive, so let us try that in a sentence instead by considering the following in the context of a daily meeting (As an example): –

• agile says that we should have a daily.
• flexible says that we should have a daily.
• adaptive says that we should have a daily.
• Scrum says that we should have a daily.
• Kanban says that we should have a daily.

Only the last two of those sentences make sense. We can be agile, flexible or adaptive and yet they cannot tell us what to do. In the same way Scrum or Kanban can guide us what to do and yet we cannot be Scrum or Kanban. We can however be an agile team, a Scrum team, an XP team or a Kanban team because the words do make sense in that context, albeit with different meanings. In the case of an XP team it is actually a team that uses eXtreme Programming values, principles and practices. The same would hold for a Kanban or Scrum team. Whereas in the context of an agile team it would be a team that exhibits the traits of agility, such as being able to adjust, move and understand quickly and easily.
By the way I deliberately wrote agile, flexible and adaptive without capitals in the bulleted list because they are not nouns and I wanted to underline that point.

We can be agile or not be agile, but we cannot do agile or not do agile. We can gauge our agility and become more agile over time. Imagine that agility is like a sliding scale from 0 to 100* and we are somewhere on that scale. The various methodologies can help us move up that scale. Some of the methods and methodologies we choose provide more support in this regard than others. Yet they can all guide us when we use them properly.

* Just to note: that sliding scale of agility keeps moving the bar as to what 100 is means. What might have been deemed as in the range 90-100 agility 10 to 15 years ago might be much lower today.

I suggest that we be open and honest and not try to shoehorn people into a way of working that muddies the waters of communication. If we want a team to be agile let us give them enough freedom to be ever more agile as they improve. If we want a team to be a Scrum team then let us help them use Scrum and to do so in the context of realising that Scrum is a process management methodology (The Scrum guide calls it a framework but it comes from empirical process control) and use Scrum to manage the process by which the team works and improve that process. The same holds for Kanban, XP or any other way of working.

In summary
Let’ us try and understand the different aspects of developing agility and the various methods and methodologies than can help us to get there. Then let’s find a way to work together and make the great aspirations around agility a reality rather than conflate terms and lose sight of the aspirations we really want to achieve.

What will becoming more agile really give us and what does it need? The manifesto for agile software development gives us the values and principles that we can use to guide us towards increasing our agility. However, we should not blindly follow someone else’s ideas without knowing where we are going. Therefore I want to discuss my thoughts on agility, what it can give us, as well as some ideas where we might look to improve along the way.

The first thing to realise is that increasing agility is a journey towards a moving target. What was considered the pinnacle of agility 10 years ago is no longer the pinnacle today. Realising this simple truth we realise that anyone selling an “Agile transformation” may want to consider their phrasing of what we are doing. A transformation implies a start and an end. The problem is that the journey towards greater agility knows no end and we can always improve. With that said we can review some ideas around what being agile is all about and discuss those points. We can then look at some outcomes to focus on so we might find a guide to inform us about the direction we are going. Those outcomes can form the basis of teams and companies deciding, for themselves, what they want and how to change course to gain greater agility. It is also worth noting that there is no exhaustive guide for how how to become more agile because each situation is different. The points below are ones that I think are pretty universal.

A focus on people
The manifesto for agile software development has, as we have already seen, put a focus on people. At the end of the day we are working to sell our products or services to an end customer, who is normally a person somewhere in the world. We also have people working to create the product or service and we need to look after them to make sure that they can do their best work.

In terms of employees we need to:

• Give them the freedom and support they need to make the best decisions and do their best work.
• Provide the psychological safety to address problems and speak up so as to improve.
• Make sure that they have all the skills they need and that they can learn and progress.

In this regard I always liked the following way of thinking “Give people all the support and training so they can find their ideal job and then create the environment that they already have that job with you”. The idea is simple and makes sure that you have the best employees you can find and that you will find it easy to hire more people when needed because you will have excellent word of mouth about you as an employer.

When we consider our customers we have two major factors in play. We want to

1. Earn as much money from them as possible
2. Like them to come back and sell our products and services through word of mouth.

There are many good examples of this in the world and we often see how most successful companies put a strong focus on quality, customer engagement and making the customer happy. This leads to greater sales and the cycle repeats. The most simple way to deliver customer satisfaction is to be sure what your customers want. The best way to achieve that is by talking to them and asking. We then get into another core part of agility which is to create a finished product increment, put it in the hands of potential, or existing, customers and find out what the next most important bit of value that customers want is. Then we build that and the cycle repeats.

The flexibility to react
One of the key points around agility is the ability to remain flexible and change direction. We might think that we know what our customers really want and yet we will only be sure when we put some working software in their hands and see their reaction. There is a huge problem with developing new things, and that is that people don’t know what they want until they see what they don’t want because they are using it. We also have another problem that many customers don’t know what is possible and therefore cannot know what they want. As such we need to consider how we can rapidly win valuable customer feedback. We need to design measurable experiments into our product releases to learn so that we can fail fast and adjust course.

This philosophy changes how we want to write software. If you need to always remain flexible then we come back to good design principles around modularity, high cohesion and low coupling, simplicity, etc. When we design our work we need to consider not only how brilliant our solution is but also how easy it will be to change in future. As such clean and simple code will almost always win out over some really clever solution. Documenting the problem we are trying to solve and the ideas of our solution in comments is valuable and makes future refactoring easier.

Iteratively gaining feedback on a working increment of your software
Two concepts around agility are iterations and increments of software. An iteration is a step on the journey to the final product, a bit like the never ending journey of taking steps to increase your agility. Where the real difference comes in is with increments. You would ideally deliver working increments of your software on a regular basis. The more rapidly you can do so the more agile you have the potential to be. The absolute ideal state is to be in a permanently shippable state. This is the current gold standard of continuous delivery. Being able to deliver working software regularly allows you to put your software in the hands of customers, or potential customers, and see their reactions. You can gauge your progress and customer satisfaction. You can observe what you need to change to improve your product and ask customers for feedback. You can then change direction, as needed, based on that feedback.

Being outcomes focused
Objectives bring people together and are multilayered. You might have a product vision and objectives for the year, quarter and month or week. This helps to guide where we are going and ensure that we are all speaking the same language and pulling in the same direction. Just putting a lot of work into a project and delivering output will not be nearly as successful as making sure that the entire team is on the same page and working together.

I mention longer term planning like yearly or quarterly plans, it is important to consider that the longer term the plan the less detailed it should be. We should spend the most time on what we are about to work on and use longer term plans purely to guide our direction in the knowledge that they will most likely change. It is not the plan itself that is important but the act of planning. Planning lets us discuss options and possible hurdles in our path before we ever get there. Planning gives us an overall direction. Plans themselves rarely, if ever, survive first contact with reality. As general Dwight Eisenhower said “In preparing for battle I have always found that plans are useless, but planning is indispensable”. The same is true of planning an agile software project. We cannot know what reality, or changing customer demands, will throw at us, but the act of planning allows us to be more ready and able to adapt when the unexpected happens.

Some outcomes that might help to guide us
If we consider our journey towards increasing agility to be outcomes focused then it might help if I provide a list of a few outcomes that I think are helpful. I will then briefly describe why I think they are important.

• Smile.
• Sooner (Delivery).
• Safer (Delivery and interactions).
• Quality.
• Value.

As we have already discussed agility is about people and we want to put a smile on the faces of our customers and also our employees because happy customers sell our products through word of mouth and happy employees are more motivated and deliver better work. We want to deliver our products sooner to win valuable feedback and want to do so more safely with fewer errors and rollbacks or fixes. We also want to ensure that we have psychological safety so that people will address actual problems rather than ignore them because they are resigned to the consequences of speaking up. We also want to focus on quality because technical excellence enhances our ability to remain flexible and make changes going forward. Also the DORA state of DevOps report has repeatedly shown that increasing quality also increases long term development speed. The last one goes hand in hand with several other objectives here and that is to deliver value to our customers which makes them happy and keeps us focused.

In conclusion
To me agility is about a focus on people and delivering high quality and valuable software to customers quicker and more safely. If we can get there we should be in a good way. If you want to focus on other objectives that is of course totally fine. Just make sure that your objectives are well thought out and align with the manifesto for agile software development, or your amendments to it if you want to try and improve it.

This blog has been inactive for a while. The reason is that I changed employers and wasn’t doing as much that I considered to be interesting and worth blogging about. I have also started going in a different direction in my career, focusing more and more on agility. In my opinion agility is often misunderstood and that is what I want to focus this blog on for now.

I want to focus on what I consider to be agile software development, the downsides of how it is implemented and some advice around that. Then I will see how things develop in future and let it organically grow from there. I also want there to be a bit of a story through the topics so I plan to cover them in a bit of an ordered sequence for now. Some topics I plan to cover include: –

• The agile manifesto and principles.
• Some of the major methodologies (Scrum, Kanban and XP).
• Meetings, why many are not effective and how to improve them.
• Thoughts around estimating, planning, etc.

Before anyone comments that Scrum is a lightweight framework not a methodology, please realise that the term “lightweight framework” doesn’t really mean anything and doesn’t tell you anything either. Scrum came from empirical process control and and can more fully, and correctly, be described as a process management methodology. Also yes, I might challenge a few commonly held beliefs in the hope of making anyone who reads this blog think about things in a different way. I may be right, I may be wrong with what I write. What is important is that we think about things and have a constructive discussion to help us all improve.