How many % of the requirements are necessary and used?

In mostly every agile training people are shown the results of Chaos Report of The Standish Group which shows how many % of requirements are/are not used.

Chaos Report – The Standish Group

These numbers are very important for agile teams. It is proof that big requirements upfront (BUF) makes no sense. In case of constant changes, there is no other option than continuously consider requirements, evaluate their business impact, risk and cost and develop them iteratively. See more details in this article.

Agile Transformation Metrics

Can be transformation measured? Hard to say…

One aspect of the transformation that can be measured are goals, problems, and the vision of the transformed company. OKR method is helpful here for the definition of objectives and key results. Problems need to be analyzed with root cause analysis. These root causes should be measured by specialized metrics so we are aware of how blockers are removed from the system.

So do you deliver faster? Do you improve the satisfaction of your customers? What about your employees?  How much do you innovate? What does it mean? How many requirements were still vague? Did you deliver your promises to the customers?

Another aspect of agile transformation is people who are part of it. All those team members, managers, product owners, scrum masters. How much do they apply agile principles in real life? How are they disciplined? Do they follow selected methodology like Scrum or Kanban? DO they apply XP practices? Are they satisfied with agile approaches? There are checklists available on the Internet, there are some tools. Our colleagues from ScrumDesk Consultancy do such assessments adapted for companies.

It is very important to use measurements for improvements, not for blaming! To identify system-level blockers, to improve the way of working. 

Agile transformation metrics

An Agile principle is to deliver a working product. Therefore, if you still need to measure something, it should be about the product and its delivery:

• Lead time – how long does it take to deliver the idea?
• Cycle time – how long does it take to implement the idea from the moment of the start of development?
• Sprint burndown chart – How much work is remaining in the sprint?
• Release burndown chart – how much work is remaining in the release cycle?
• Cumulative flow chart – what is the throughput of the team?
• Value chart – do we add value to our product?
• Complexity chart – do we estimate correctly?

Of course, feel free to measure anything else. Like Customers satisfaction (Net Promoter Score), employees satisfaction, quality of development, quality of service, number of defects, support cases, etc.

In agile you should measure blockers, ideas implementer, experiments started and finished, the learning, etc. Companies, where requirements are too vague, used to measure even readiness over time.

Agile metrics

Think about how to measure your goals and remove your problems. Because these are important. And what about the measurement of people’s performance? Well, transparency and often retrospectives solve that without the necessity of further metrics.

Split resources into Agile teams

Agile principles ask organizations to assign team members 100% of the time to one team. Ideally. This is not easy especially at the beginning of Agile transformations.

There are some roles that are not economically easy to have in every agile team even it makes sense to have such a role in the team.

And that might be a key. The question is if you need a role or capability in the team. The capability can be built by knowledge share increase. Such capability can be provided by any role in the team, whoever wants to help with it. Organizations used to even establish communities, chapters to support knowledge sharing.

Anyway, shared people is reality. Typically we see in companies people like architects, user experience designers, business analysts.

Capacity split approach

The first approach is to let them specify % of capacity they will invest into particular teams and let them check that %, adapt it based on plans and reality of teams they support. This approach has its cons as well. Shared team members will be asked to join multiple planning sessions, daily standups, reviews, and retrospectives.

Let people adapt how much and when they are really necessary. For example, they can join your daily standup once they started to work on the item from your sprint backlog. Of course, full transparency is expected from everybody.

Capacity Planer in ScrumDesk

In the case of shared people is even more important. Who assigns work to those people? Well, they pull a work based on priorities. Priorities that are agreed upon by product owners upfront, which are transparent after the release planning sessions.

ScrumDesk tool can help you manage capacities and level the team members capacities even in the case of multiple teams.

Team of Experts approach

Another approach is to organize such a team per expertise (UX design team), and let them manage their own sprint backlog, do standups, etc. This will require some product ownership and it will increase dependencies within the product development.

Choose your approach wisely

Which approach is better? It depends on your vision of the transformed organization, the current problems, and blockers. There is no easy answer to that question. Try some, inspect the results and adapt!

Agile in a distributed environment

Is Agile possible in a distributed environment? Yes, if you do not think about it as a blocker. Not if you do not want that.

Of course, Agile is much easier in a collocated environment where all team members are in the same room. But even here, Agile is simple, but not easy.

Distributed environment makes Agile hard just because of one very important aspect. Agile is about people and interactions. It is in the DNA of Agile. Once people are not thinking about others in the team, once they do not actively work on collaboration and communication, Agile will not help to improve things.

Today’s world offers us a lot of technologies that can overcome problems with distance. But it is still necessary to want to talk, explain, understand, listen and provide feedback even with those tools.

Tools for distributed Agile teams

In ScrumDesk we do sprint planning over Microsoft Teams. We have our work tracked in the ScrumDesk Kanban boards itself, but that doesn’t mean we do not need to talk.

ScrumDesk integration into Microsoft Teams chat rooms

We use Slack for chat and integration with other tools (Microsoft Teams, GitLab)  to stay informed. But we also discuss problems, ideas, and solutions in chat rooms. Our team is a very distributed one, but that doesn’t stop us in pair programming over MS Teams, or code review with Git pull-request capability.

Travelling is a key

For important sessions, we try to meet in person. Because brainstorming is much more efficient in person.

Backlog refinement or release planning sessions are better to be done in person. Invest a few bucks into travelling. It is once per 2-3 months.

Travel to all locations. Rotate locations so everybody feels the pain of travelling. Let yourself be equal. You can understand the culture, habits, and environment of your team members this way much deeper.

Later, with all those tools, life will be much easier. Because you already will understand the language, mimics, and limits of your colleagues.

We observed many teams working great in an agile environment. The limit is not the distance, the limit is the willingness to support each other, understanding of the vision, being sticky to promises were given, being disciplined, transparent and responsible person.

Dependencies of teams in Agile

How to deal with inter-team dependencies? It is not easy to answer the question. The differences might be of different types and therefore the solution of such dependencies will be different.

In Agile we try, as a principle, to limit dependencies by the restructuring of products, change of architecture, and sometimes even with a change of technologies and company structure/organization chart. We want to achieve the capability to deliver end-end value for customers and organize teams necessary for its development into groups supporting some value stream.

Dependency in the value stream is natural and can be easier to manage. Such teams should be not built based on the technology layer (for example database, backend, front-end team) but rather on the product/system part. End to end. One such example is Spotify company there can be a team for a player, playlist management, data analysis, etc.

Teams in value stream follow these additional principles for easier synchronization:

1. Work is planned ahead not just for one sprint but in release (program increment) cycles.
2. Work is visualized with help of program boards.
3. Problems are broken into more details by aligned product owners.
4. Teams help to identify dependencies and risks not later than in release planning and sprint preplanning sessions.
5. Once the work has been done by the team, Scrum Masters inform other depending teams about the status in Scrum of Scrum events.
6. ScrumMasters meet daily to synchronize inter-team dependencies.
7. Teams should incorporate “We are vendors, we support customers whoever is it” way of thinking. Anybody outside of the team is our customer we should support and help to be successful. It doesn’t matter that he is a colleague we meet in the kitchen.
8. Blockers have to be visible and solved as soon as possible. Management should collaborate with Scrum Masters on that.

Program Board example

If it is not possible to change the structure of the company, try to build virtual agile teams at least.

The Product Owner and ScrumMaster responsibilities

Scrum simplifies roles necessary for product development. It provides just three roles.

The Product Owner is fundamentally responsible for:

• answering WHAT needs to develop,
• priorities,
• acceptance criteria gathered in close communication with stakeholders and collaboration with team members.

See more about the role of the Product owner.

The ScrumMaster is responsible for:

• facilitation,
• organization of meetings and Scrum ceremonies,
• removal of blockers,
• system-level thinking and optimization.

See more about the role of ScrumMaster.

The agile team is responsible for:

• answering the question HOW to develop the solution,
• identification of blocker,
• estimation,
• delivery of the working product.

Well, yes and no.

Agile is not a silver bullet. It fits perfectly into an environment where a lot of changes need to be considered and people are able to adapt continuously. Non-agile approaches on the other side fit better for an environment where a lot of effort should be invested in upfront risk management, security, and safety due to rigorous processes.

That doesn’t mean, however, that agile practices can’t be used even in a non-agile environment. Daily standups, transparency via Kanban boards, a regular check of plans with help of release planning, and agile roadmapping might be very helpful. Practices like pair programming, code review, often feedback in regular reviews, and regular “lessons learned” (retrospectives in agile) help to achieve great quality of the product and processes.

So why stick to black or white when we can combine the benefits of both worlds? In some cases more from agile, in some cases more from the non-agile world. But be aware, that once you start with agile in your IT, business, and operation will be necessary onboarded soon as another way you will have a powerful engine without fuel soon.

How to incorporate Business Analysts into Scrum and sprints?

If your product is simple, business analysis is typically done by the product owner itself. The product owner is responsible for the return of investment so the business analysis is a natural part of this responsibility.

The complex product however often fulfill the requirements of different market segments, user, with different jobs, pains, and gains. The product owner will need help to understand the context of the system and all the important details. A business analyst is a role in a traditional non-agile environment who takes care of an understanding, analysis, and proposal to target these areas.

Business analysts are in some agile teams regular members of agile teams who work closely with the development team on sprint backlog items that should be delivered in the sprint. In such a case the work of business analysts is transparently published on Kanban boards of the team.

Another approach we see in real life is business analysts who are part of the Product Owner’s circle, a micro team of people who prepare backlog items for the next iterations upfront for agile development teams. Some other roles who work in the Product owner’s Circle are people from sales, marketing, UX, architects, and operation. The main goal is to have requirements ready for the development communicated with stakeholders. This approach leads to a separate kanban board for the product owner’s circle micro team where they track the status of preparation of requirements. Once prepared, items are dragged to the team’s kanban board in the next sprint planning session. SAFe calls such PO circle’s board Portfolio Kanban.

Portfolio Kanban

Agile, Scrum, Kanban. What is the difference?

Agile is a group of software development methodologies, methods, and practices based on iterative development. Requirements and their implementation evolve through collaboration in self-organized multidisciplinary teams.

Agile manifesto values

Agile Manifesto principles

Agile is a mindset that welcomes changes as a driver of continuous improvement that helps fulfill customer, business, and team satisfaction. Agile is represented by frequent inspection and adaptation, self-organization, accountability, disciplined processes, and rapid delivery of high-quality working products. Agile prefers to deliver working products instead of perfect documentation with the continuous support of customers as a reaction to changes. Agile prefers people & interactions over tools and processes.

Agile values discipline, feedback, courage, openness, transparency, and delivery of commitments/promises.

Scrum implements an Agile mindset and Agile Manifesto in the area of project management. Scrum is a lightweight project management framework (it should be adapted to the company needs) that is quite simple (3 roles, few ceremonies) and provides guidance on how to develop working products in short iterations (timeboxes of 2-3 weeks) that are planned, validated, and reviewed regularly. Scrum fits well for teams with creative work where the process might be different for different types of activities (i.e. software development).

Kanban is a scheduling system for lean manufacturing and production that has been adopted in software development as well. Kanban helps to improve the efficiency of a manufacturing process. Problem areas are discovered by measurement of lead and cycle times, targeted by root cause analysis and system-wide optimization. Like Agile, Kanban is based on high transparency. Software development teams combine Kanban principles and practices with other agile methods:

• Visualize work – Kanban index cards are used for evidence of requirements and tasks on Kanban boards indicating the status of the work.
• Limit work in progress with help of WIP limits that help teams to focus on the most important work, finishing it first and only then continuing with less important items.
• Focus on the flow – develop items based on the order defined by the business and customers in the shortest possible time, but with the highest level of quality. This is achieved by a collaboration of a multi-disciplinary team that even incorporates automated solutions for most boring activities.
• Continuous improvements – everybody is responsible for the identification of waste, proposals of improvements on a regular basis, and implementation of improvements to achieve the best efficiency on the system level, not just local improvements. The work, flow, quality, throughput, and lead time are measured.

Compared to Scrum, Kanban is better for an environment where activities are repeated. For example, call centers, support, maintenance, etc. Kanban doesn’t work in iterations, but the principles of planning, daily standups, review, and retrospectives might be applied as well. These are practices that simply make sense so why not apply them?