The goal of Agile software development is, well, to be agile. This means you should be able to react fast. This requires feedback. In this blog post, we are going to explore various areas where feedback is relevant.

Context

We all know the famous path with deviations:

Software development can look like that. You would like to hit a target, that is here a functionality offered to the user. There is an ideal path (dotted path) on which you deliver the intended functionality on the first try without problems underway. This is not realistic. There are always deviations from the ideal path, e.g., missed requirements, bugs, bad design that needs rework, etc.
The goal is to keep those deviations to a minimum and to detect them early. The earlier they are detected, the cheaper they are to fix.

#1 Exploration before going into details

Depending on the risk, it makes sense to explore certain things before starting an implementation and going into details. Is this API you don’t really know well, really delivering what it should? Hit it via Postman or any other API client to check.

#2 Defining expectations

If a user story is started, it often makes sense to define the high-level expectations in tests. In this context, you should put each acceptance criteria of the story into the cheapest test to prove that the acceptance criteria are fulfilled. If you have covered that, you basically know, when you are done with your story and have reached the defined goal.
It is important to use the cheapest, i.e. simplest, test possible because you want early feedback. It doesn’t make sense to check acceptance criteria in an expensive and cumbersome UI test if it can just be validated in a simple unit test.

#3 Compiler and Linter

Depending on the technology there is immediate feedback when typing code. Because the compiler and linter in a modern IDE show that red squiggly line underneath code that is not as it should be. This is fast feedback and without it, we would lose a lot of time.

#4 While doing TDD

TDD is all about feedback. The most important aspect is not the feedback about whether your code works. In my opinion, the crucial part is the feedback about the design of your code. Is it easy to use and to test? Do I need to set up a lot for my test? Does someone understand what the code is doing from the tests? This is early feedback within seconds or minutes.

#5 Build

The build is the most obvious one. Building software and running all the tests is usually done anyway. Depending on the project this might already happen locally on the developer’s machine or only later on an external CI/CD system. It gives you feedback and answers the question if the whole system is still working. This depends also on the scope of the build. You have to make a trade-off. Building the whole system gives you full feedback about any side effects. Building only part of the system is faster.

#6 Integrate

Integrating your code changes with the main branch shows you if your changes still work in a larger context. Also, this might be the version that is usually deployed onto a dev or test system where further tests are conducted. These tests give you additional feedback.
Important here, is the feedback the other way around. If I build something, I would like to prevent it from being broken by others. Therefore I have to provide tests around my new code. Those tests should provide other developers (and myself in the future) feedback. This feedback should help others to not break my code.

#7 Pair programming

Pair programming gives you very immediate feedback. It provides a feedback loop possibly as short as the compiler and linter (depending on technology). The scope of the feedback is not only the code’s functionality but also the design. This makes pair programming valuable. Design errors that are hard to correct can be spotted early in the context they are created.

#8 Pull Request

This is the feedback I do not like, but in some contexts, it might still be a good idea. Pull request comments are added asynchronously, late, and out of context. It is usually hard to spot design errors in pull requests. Other feedback mechanisms are preferable.

#9 Users

A feature is useless if users do not want to use it. Similarly, if a feature does not work as expected by the user its value decreases. Users are one of the most valuable feedback sources in agile software engineering. At the same time, they are usually distant from the developer. It is important to integrate the user in the overall feedback loop to also get early feedback for this case. Spending two weeks on a new feature that is useless for the software’s user is a lot of waste. Therefore, users should be included in the software development cycle early and often. On the other hand, it can also mean that software should be delivered early and often.

#10 Monitoring and analytics

Finally, data does not lie. While monitoring should provide us with data about the performance and errors of our features, analytics gives us an idea about how our software is used. This can provide us with feedback more objectively.

We see feedback in agile software development is crucial! A Lot of places where we do not really think about feedback are important. It helps us to deliver the right features and the features in the right form.

The post 10 Times Feedback is given in Agile Software Development appeared first on Ronnie Schaniel.

• 📬 Done means something is realised that probably helps the user
• 📌 Definition of details can be postponed
• 📁 Clear structure helps to prioritise
• 📝 Stories are understood by users and stakeholders
• 👩 It is clear that a user is the target audience

Next, let’s deep dive into those advantages and discuss them in detail.

Done means something is realised that probably helps the user

What happens if you have user stories like “Interface X delivers value Y in format Z”? You are not sure if something valuable to the user is delivered when the story is done. On the other hand something like “As a registered user I can go through a ‘password forgotten’ process, to ensure I can always log in” has a clear statement and benefit. As soon as this story is done the user is able to recover when forgetting his password. That makes the user happy and most likely decreases the amount of emails in the support department.

As soon as the story is done value is realised. Given that the story is released to at least a subset of users and actually satisfies those user’s need.
Additionally, if the story is independent from other stories, you are sure you can deliver the story independently and still create something meaningful for the user. So, no need to discuss a lot about dependencies between stories.
You can also read our post about the frequent delivery of value to understand the importance of this point.

Definition of details can be postponed

When you define a user story from a user’s view, you can omit all the technical and design details. Like that you can postpone those decisions to the last possible point in time. This ensures that you are basing the technical and visual design decisions on the latest information. Furthermore it also means you did not waste time with unnecessary work if a user story is put into the bin.

Clear structure helps to prioritise

When user story descriptions follow a certain pattern it is more likely that they end up having the same abstraction level. Things with the same level of detail are easier to sort and prioritise. Let’s have a look at the following example. You can decide for yourselves which variant is harder to prioritise:

In both cases we just add a link (and a whole “password forgotten” process for the first one). In the second variant it becomes clearer what the user (and the company) gains from each story.

Stories are understood by users and stakeholders

Having a story written from a user’s point of view makes it clearer to understand for all people involved. Users or customers don’t need to ask what changes if interface X delivers value Y. Instead they know what they are getting. The discussions around a story between developers (and/or PO) and the user can focus on the problem to be solved without having too much technical details that only distract.

It is clear that a user is the target audience

The user is explicitly mentioned. Hence, the solution should always be designed having the user in mind. Compare this to too technical stories where the user doesn’t find its place. There the user’s need is neglected and we might implement the “story” without really solving the user’s problem. This only causes rework in the end or unhappy users. A software is not something that is created just to offer some features. A software is a product that helps its users to do some tasks or solve problems. Finally, the target audience focus means that we know from where to get feedback about the implementation. Then we can iterate and improve.

Conclusion – User Stories from a User’s Perspective

As always with Agile development, practices should probably differ from team to team. Every team is different and chooses its own best way of working (see also this article). Of course teams can always break down work into smaller chunks or tasks that are then more technically formulated. But having the user story as a base gives the developers the right focus to deliver something of value to the users.

Please also be aware of the following points when using the “As a … I … such that …” pattern:

• Not everything needs to be a user story. Alternative approaches like job stories could be more fitting in some cases.
• When expressing a certain user story in the pattern doesn’t feel right, then stop. Try it in another way. But just have in mind that the goal is to deliver value.

That is why I emphasised the user’s perspective in the introduction rather than the exact format.

The post User Stories Defined From a User’s Perspective appeared first on Ronnie Schaniel.

The origins of self-organising Agile teams

Citing the Agile Manifesto and its principles is always a bit tricky. It’s more than 20 years since its creation. Hence, in this time we hopefully learnt something while also the environment changed. Nevertheless we can still find value in its statements:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
(…)
“The best architectures, requirements, and designs emerge from self-organizing teams.”

From the Agile Principles

So, the 17 software developers coming together at Snowbird in 2001 mentioned the following:

• The best software emerges from self-organising teams
• Trust the team to get the job done
• Have motivated individuals in the teams
• Give these individuals the environment and support they need

Surely there must have existed self-organising teams also before the year 2001. But with the creation of the Agile Manifesto it was clearly specified. Next, we have a closer look at those principles and try to give an idea what it implies for our day-to-day work.

The best software emerges from self-organising teams

I put the term software for architectures, requirements, and designs. If you optimise these three parts, you are more likely to also get better software. But why do the best architectures, requirements, and designs emerge from teams that are self-organising? Before explaining that, let’s have a look what the alternatives are:

• Architecture and design is dictated from outside the team. Teams do not have that much influence on architectural decisions and are left to accept.
• Requirements likewise come from instances outside the team. The team itself doesn’t talk directly with the user.

So, let’s see what improves when the team is in charge.

Architecture and Design

The team that develops a system, knows the system best. Additionally they are nearest to the system’s development which means that they are able to take and apply decisions quickly. In their day to day work they experience what it means to extend and maintain the system. Therefore the developers should be able to judge what design and architectural directions are most promising.
Of course it does not mean that developers should ignore the outside world of architects and other teams. Actually they should take inputs from the outside seriously and evaluate them based on their good knowledge of the software under development.

Requirements

Both, the users and the developers know a software system best. The users obviously are using the system with all its features in the context the system is intended for. The developers know what is possible from a technical perspective. If we bring those two parties together conversations about the software details are very likely to happen. This is actually the point where a user story can be captured (it is not called “user story” for no reason). Besides that, the communication path between user and developer is in this case of length 1. No instances in between which could transmit informations in a distorted way (or manipulate and even bring their own view into it). Ultimately, we have short feedback loops.
In the end, self organisation also means that a team decides what they work on. Management only gives vision and strategy, no specific work assignments. The team can figure out with users and stakeholders which direction is most promising for value delivery.

People nearest to the work can make the best decisions.

Trust the team to get the job done

Every team is different since they consist of individuals with different skills, backgrounds, and experiences. At the same time every team should strive for continuous improvements within the team. Consequently every team takes different decisions on improvements, e.g. how to approach work, how to interact with stakeholders, and so on. This in turn makes every team look differently from an outside perspective.
Nevertheless, managers often try to compare teams, control them, and measure them. But what happens if a team feels they are evaluated based on externally visible KPIs? The team optimises towards those KPIs to look good from an outside perspective. Hence, their improvements take a wrong aim and not anymore try to improve value delivery. The result is a suboptimal way of working.
The only thing an Agile team has to guarantee is the ability to continuously deliver value. Stop managing the team and start trusting.

Have motivated individuals in the teams

Usually software developers are very happy about the actual work that comes with their job. They like programming and want to program. A part of us even programs in our spare time. As always there are a few exceptions. People that generally don’t like developing software should just not develop software and change their job.
Anyway, if now these motivated programers can work on their own architecture and are allowed to talk to the user, I’m convinced they are even more involved and want the software product to succeed. Developers don’t want an assembly line type of job where they just receive detailed and predefined requirements, implement and ship them. They usually want to be creative and solve problems to create great software products. And, opposite to what some people might think, programmers also like to talk to the user and build a relationship. They are humans in the end, a social species. And developing software is a highly social activity.
Finally, despite all the things mentioned above, there could still exist some obstacles in the day-to-day work of a developer. And those obstacles can decrease motivation. This is where the next part of this blog post comes into play.
It’s not only about motivated individuals though. You also need the right skills in the team. Self-organisation becomes easier if the team is cross-functional. If you are too dependent on others, it’s more difficult.

Give the environment and support they need

How can an Agile team continuously deliver value and excite users? Is it because they work hard, develop fast, and increase their velocity? No, it’s about continuous improvement and removal of obstacles. It’s about keeping a sustainable pace. If procurement takes too long, fix that. A team that needs a big screen for mob-programming doesn’t need it in 2 months, it needs it now. If you’re a manager don’t tell the team how to work. Instead, ask the team what they need for working in an ideal way.
At the same time, asking critical questions to the team is needed too. Trigger the team to reflect on their way of working with inputs from the outside. But always understand that they are self-organising.

Conclusion

Agile teams are not self-organising for no reason. There are thoughts behind this term and specific details why a team should organise themselves. If someone is claiming that his or her team(s) are self-organising, reflect on the above mentioned points.

Finally, I could imagine that self-organisation can also be pushed too far. Especially if you are working next to other teams, it might make sense to find a common ground. Because the goal is that all the teams can continuously deliver value. But if the other Agile teams (and the whole organisation) also understand self-organisation, it will not be too difficult to find a solution.

The post Why Agile Teams Should Be Self-Organising appeared first on Ronnie Schaniel.

In this article we construct a model for business value realisation and demonstrate based on it what such companies actually loose. We focus on this business value realisation and ignore for a moment other disadvantages of not releasing frequently. These would include: larger and therefore more riskier deployments, possible overload with productive defects, or later feedback.

The Business Value Realisation Model

Context: we assume that we’re having a team of 8 developers who are working on User Stories. These User Stories are done within 1 day and could potentially be released to the users. Further assumptions:

• A User Story realises a constant benefit of 100$ per day for the business
• The software in our case is only used during working days and the 8 developers work during all the working days
• A single developer finishes 5 User Stories per week
• Once a User Story is completed it could be released in the evening and start to realise the benefits from the next working day on

What exactly is business value here? It’s the monetary benefit resulting from users using our software.

Now we are set and ready to explore different release frequencies.

1) Releasing every 4 weeks

Our 8 developers are completing 8 Stories per day which results in 800$ value ready to deliver. So, after 20 days of implementation there is 20*800$ = 16’000$ ready to be released. On the evening of the 20th day the release is taking place and from the 21st day on the business now realises a benefit of 16’000$ per day. On the 41st day the value realised sums up to 352$ (20*16’000$ + 1*32’000$). Below table shows the total gained value until a specific day where green cells mark a day after a release:

2) Releasing every 10 days

Every 10 days 8’000$ more value is ready to be gained if the software ends up in production and is used by the users. In this variant the first release happens on the evening of the 10th day. This means we start to get value on the 11th day. Further deployments happen on the 20th, 30th and 40th day:

3) Releasing every 5 days

It should be self-explaining at this point:

4) Releasing every day

Finally the software is released every day. That means already on the second day the benefit of 800$ is gained:

After 41 days we reach 656’000$. Which is equal to (40² + 40) / 2 * 800$.

On a chart the 4 variants compare as follows:

The value created after 41 days is almost doubled when releasing everyday instead of only every 20 days ($656’000 vs. $352’000).

Conclusion

While this model of course does not correspond exactly to reality, it gives an idea about where value is lost. Or more positively put, it shows how you can increase your value realised.

Don’t build for a release. Release what you build.

And of course: keep your User Stories small!

The post The Cost of Not Releasing Software Frequently appeared first on Ronnie Schaniel.