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

Chaos Report – The Standish Group

 

These numbers are very important for agile teams. It is a proof that big requirements up front (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.

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 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 are 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

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

Agile metrics

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

 

Agile asks people to be a team member for 100% of the time. Ideally. This is not easy especially in the beginning of agile transformations.

There are some roles which 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 sharte 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.

The first approach is to let them specify % of capacity they will invest into particular teams and let them to 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, adn retrospective. 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. In case of shared people is even more important. And who assign a work to those people? Well, they pull a work based on priorities. Priorities which are agreed by product owners upfront, which are transparent after the release planning sessions.

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

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!

Is Agile even possible in a distributed environment? Well, 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 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 the distance. But it is still necessary to want to talk, explain, understand, listen and provide feedback even with those tools.

In ScrumDesk we have sprint planning over Skype. We have our work tracked in ScrumDesk tool itself, but that doesn’t mean we do not need to talk. We use Slack for chat and integration with other tools to stay informed. But we also discuss problems, ideas, and solution in chat rooms. Our team is very distributed one, but that doesn’t stop us in pair programming over Skype, or code review with Git pull-request capability.

But, 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 few bucks into travelling. It is once per 2-3 months. But do travel to all locations, rotate locations so everybody feels a pain of travelling. So you are equal. And you can understand the culture, habits, and environment of your team members as well.

Later, with all those tools, the 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 willingness to support each other, understanding of the vision, be sticky to promises given, be disciplinned, transparent and responsible person.

It is not easy to answer the question: “How to deal with inter-team dependencies?”. The reason is simple, 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 an 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 technology layer (for example database, backend, front-end team) but rather on product/system part. End to end. One such example is Spotify company where there is 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, ScrumMasters 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 ScrumMasters on that.
Release-Planning-PSI-Program-Plan-1

Program Board example

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

 

 

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

  • Product Owner responsible for answering WHAT needs to develop, priorities and acceptance criteria gathered in close communication with stakeholders and collaboration with team members. See more about the role of Product owner.
  • ScrumMaster responsible for facilitation, organization, removal of blockers and system-level thinking and optimization.  See more about the role of ScrumMaster.
  • The agile team responsible for answering the question HOW to develop the solution, an identification of blocker, estimation, and delivery of working product.

Well, yes and no.

Agile is not a silver bullet. It fits perfectly into an environment where a lot of changes needs to be considered and people are able to adapt continuously. Non-agile approaches on the other side fit better for an environment where lot 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 roadmappingmight 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 to stick to black or white when we can combine benefits of both worlds? In some case more from agile, in same case more from non-agile world. But be aware, that once you start with agile in your IT, business and operation will be necessary onboarded soon as other way you will have powerfull engine without a fuel soon.

 

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.

Complex product however often fulfill requirements of different market segments, user, with differnt jobs, pains and gains. Product owner will need a help to understand the context of the system and all imporatn details. Business analyst is a role in traditional non-agile environmewnt who takes care about 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 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 are business analysts who are part of the Product Owner’s circle, microteam of people who prepare backlog items for the next iterations upfront for agile development teams. Some other roles who work in 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 separte kanban board for the product owner’s circle microteam wherre they track the status of preparation of requirements. Once prepared, items are dragged to the team’s kanban board in the next psrint planning session. SAFe calls such PO circle’s board Portfolio Kanban.

Portfolio Kanban

Portfolio Kanban

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 values

 

Agile Manifesto principles

Agile Manifesto principles

Agile is a mindset which welcomes changes as a driver of continuous improvement that helps fulfill customers, business and teams satisfaction. Agile is represented by frequent inspection and adaption, 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 the discipline, feedback, courage, openness, transparency, and delivery of commitments/promises.

Scrum implements 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 very simple (3 roles, few ceremonies) and provides guidance 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).

scrumdesk scrum project management tool product backlog sprint daily standup working increment agile

Kanban is scheduling system for lean manufacturing and production that has been adopted in software development as well. Kanban helps to improve an 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. Similar to 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 an 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 to continue with less important items.
  • Focus on the flow – develop items based on the order defined by the business and customers in shortest possible time, but with the highest level of quality. This is achieved by a collaboration of multi-disciplinary team that even incorporate automated solutions for most boring activities.
  • Continuous improvements – everybody is responsible for identification of waste, proposals of improvements on a regular basis, and implementation of improvements to achieve the best efficiency on system-level, not just local improvements. The work, flow, quality, throughput and lead time are measured.

Comparing 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 which simply to say make sense so why not to apply them?

Go to Top