Faisal's Agile and Scrum Blog

Entrenched micro-management culture makes life of a self organizing Agile team very difficult. Senior people many ogrganizations like to pass orders down to the Agile Teams instead of setting direction and goals and letting the teams self organize. Many Agile teams struggle with self organization, rather self organization is one of the most difficult practical aspect of Agile and Scrum.

Micromanagement Culture

The culture of micromanagement runs deep in the organiztions. It rears its ugly head time and again even in the organizations which have adopted Agile. This stops self organization in its tracks.

It is hard to resist the urge to tell the Agile teams exactly how that specific problem must be solved. It’s even harder to resist when things start to head south. It’s when the fire fighting instincts take over and solutions are thrusted upon the Agile teams. Self organization takes a back seat.

Ivory Towers

In many cases, senior people in the organization don’t like to become an ordinary Agile team member. They think they will lose their significance. Normally, these are rather skilled people. They like to discuss the big picture, they like to do design and architecture work, but they don’t like to be part of the Agile team doing the work. They like to come up with roadmaps, solid design and architecture ideas, usually upfront Then they handover this to their ‘Agile team’ to deliver. They like to issue their orders from their ivory towers.

In such cases, bulk of the decisions and commitments about requirements, architecture and design are thus made early on in the project. In a fast changing market, new and emerging requirements mean that the upfront analysis and design work often lead to waste, and inflexible systems with very high cost of change. Increasing number of changes needed in design and implementation while dealing with the design decisions made upfront make the life of  the ‘Agile team’ very hard.

When the changes are needed, the Agile Team finds it politically hard to change the architecture and design that was provided to it by influential architects and decision makers. This causes rifts between the Agile team doing the work, and people sitting in their ivory towers passing on instructions to the Agile team. This situation hampers any self organization aspect of the Agile Team and limits the ability of the Agile team to inspect and adapt.

Learn more about Agile, Scrum and Self Organizing Teams in our Agile and Scrum courses.

What is Velocity in Agile and Scrum

Velocity is the amount of work an Agile Team delivers during a Sprint. It’s measured in story points, number of items, hours or some other unit.

What’s the point?

It gives the Agile Team an indication about how many items it will be able to complete in the upcoming Sprints. It provides no more information than this to the Agile Team or the organization.

Common Mistakes

A couple of velocity related anti-patterns are

• Velocity optimization
• Velocity comparison

Many organizations try to optimize Agile Team velocity. Management keeps an eye on the velocity trend line. They ask the Teams to improve their velocity, to deliver more. At some places, Agile and Scrum Teams and individuals are measured in terms of how many units of work they deliver during Sprints.

This carries an unintended consequence. The Agile Team, consciously or unconsciously, starts to increase the estimates. By increasing the estimates, Agile Team members ensure that they ‘improve’ their velocity. This, of course, does not translate to increase in performance. The numbers are manipulated.

Similarly, comparing velocity figure from two different Scrum Teams doesn’t provide any valuable information. When one Scrum Team’s performance is compared with the performance of the other Scrum Teams based on their velocity, it sends a signal to the Teams to ‘improve’ their velocity. And of course they do just that. Intentionally, or unintentionally, they game the system and come up with ‘higher’ velocity.

Velocity is a tool for the Agile and Scrum Team. It is not a performance measure. Using it to measure performance is akin to using lines of code to measure developer productivity. It leads to increased output, but not in increased productivity, performance and value.

Learn more about Velocity, Agile and Scrum Teams and Scrum Master roles in our Scrum Master Courses.

© Faisal Mahmood

In many cases Agile Teams which have started using Agile resist doing planning. They resist doing design. They get confused when they see the following in the Agile Manifesto,
‘We have come to value working software over comprehensive documentation’.

They tend to overlook the word value in this statement. Thus several Agile Teams refuse to do plan, design and do any documentation. Many Teams misunderstand the Agile Manifesto when it says, ‘we value working software over comprehensive documentation’. Two words that confuse Teams the most are Vvlue and comprehensive. They overlook theses words, and read it as ‘we don’t do any documentation’. Consequently, they refuse to do any documentation at all.

Two most commonly asked question regarding Agile and Scrum are ‘how much documentation should we do’ and ‘should we do documentation at all?’

Documentation is a mean of communication. Agile and Scrum encourage the Team to communicate in an interactive fashion. This cuts down their documentation needs dramatically.

Documentation is a passive way of communication. When a document is created and shared, the receiving party may interpret it the way they like. The person(s) who created the document is not there to elaborate. Any question that arise from this would either need to be documented or clarified using some other technique. This leads to a passive way of sharing information.

Agile encourages more interactive and active way of communication. Agile and Scrum encourage us to use most effective way of communication, whenever possible. In small collocated Teams, the need for documentation is usually rather minimal, but in large, more complex organizations documentation needs tend to vary.

Agile and Scrum do not say that you should not do any kind of documentation. There are cases where some sort of documentation is needed and adds value to the overall development life cycle. The Agile Team needs to ask itself a question while doing the documentation, why do we need this particular piece of documentation? And what will be the most effective way of documenting this? In some cases, a few diagrams will do. In other cases, more detailed documentation might be required for legal or regulatory reasons.

Agile and Scrum does not prohibit the Team from documentation at all. However, while creating and maintaing any documentation the Agile Team should question the value these documents. Do these documents really add value (to the development lifecycle) or are they doing it because ‘they have always done it like this’. If the documentation adds value, they should go ahead and do it.

Having a Definition of Done (DoD) is not a guarantee that the Team will produce a potentially shippable increment by the end of the Sprint.

The Scrum Team identifies a Definition of Done at the start of the project. It makes it visible. And it starts working in Sprints. But it doesn’t get to Done at the end of its Sprints. In many instances, it doesn’t even realize that until its Product Owner wishes to release the work to production. Only then the Scrum Team discovers even though it has a Definition of Done, but that hasn’t helped the Team in producing Done increments.

Static Definition of Done

The Scrum Team has created a Definition of Done (DoD) initially. But its DoD hasn’t changed over time. It hasn’t inspected, adapted and updated its Definition of Done as it has learnt more. Its DoD is static.
Over time, the Team members has not accounted for the following changes in their DoD

• Changes in the scope and the way these change affect their Done Defintion
• Their technology, build and deployment infrastructure changes
• Changes in the external systems they are dependant on
• Changes in testing infrastructure
• Changes in the Team composition

Some other changes might have occurred as well.
Of course, the Team has ignored the biggest indicators of all, that it was not getting to Done every Sprint.

Not Getting to Done

The Scrum Team has come up with a Definition of Done. And it adheres to it. However, it struggles to get Done Sprint after Sprint. Some kind of house cleaning is needed before the increment is usable by the customers i.e. the increment is Done.

By the end of the Sprint the Team ends up with half baked work which is not production ready. It either ignores end to end testing altogether or relies on testing on ‘developer machines’ only. This is the ‘it works on my machine’ syndrome. Or the Team misses out other piece of work that needs to be carried out before the increment is shippable.

Planned and Long Stabilization

The Scrum Team has planned not to get Done, even though it might have a Definition of Done. The Team or the Product Owner has come up with a release plan. The release plan calls for several Sprints towards the end of the release cycle that are named as ‘stabilization Sprints’. Some call it ‘integration’, others use more innovative names.

The Scrum Team has planned to conduct several Sprints worth of undone work right from the word go. As it get closer to the ‘stabilization Sprints’, of course, the stabilization work has increased many-fold. And it is surprised at this, again.

Meaningless Estimates And Plans

The Definition of Done is a critical agreement. The Team is unable to estimate effectively without it. It doesn’t know the complete set of requirements either functional or non functional, the set of activities that it needs to carry out before the product goes into production. It does not know how much work it should carry out during the Sprints for the items it has selected. Estimations and plans based on those estimations are misleading. These don’t mean much.

The Product Owner doesn’t not know what activities the Team is not completing. She does not know what’s the degree on ‘doneness‘ of the items delivered by the Team i.e. whether the Product Owner can go ahead and implement those items or not. This causes lots of confusion and frustration. The projections and estimations Team is coming up with are based on incomplete information. The release schedule created by the Product Owner with the help of the Team is misleading.

Long Release Cycles

The Team accumulates significant amount of technical debt in absence of a good Definition of Done. It misses out pieces of work which should have been completed every Sprint. This undone work accumulates exponentially. If the Team keeps ignoring undone work for a few Sprints it is very likely that it would need several Sprints at the end just to finish what it has already ‘built’. It will be able to release only after long, painful and costly stabilization.

Team Members should continuously ask themselves the question, ‘is our Product Owner, if she wishes to, able to implement the increments we produce without ever asking us again?’. In case the Team is not getting at that level every Sprint, it is missing some items on their Definition of Done.

Definition of Done is not a static document. The Team must inspect and adapt it on continuous basis. It must identify the gaps. It must identify the items it is missing and add those items on its Definition of Done.

Where’s the Product Backlog?

You have recently joined a Team. You go and talk to a Team and ask them about their Product Backlog. They tell you they have one. You request to see it. And they start asking each other where’s the Product Backlog stored? Some wonder whether it’s on a shared network drive while others think it’s in their inbox. No one can point out the location of the Product Backlog. A bad start indeed.

Many Teams fall into the version trap. They do have an agreement with the Team and with their Product Owner about the format of the Product Backlog. Upon inspection it become clear they have multiple versions of the Product Backlog. It’s not very clear to the Team which one is the current version? The Team has one version and the Product owner is maintaining another.

Confusing Product Backlog Items

‘As a user, I want as easy to use website’.

Requirements such as the one described by the ‘user story’ above do not convey any meaningful information. These just cause confusion. The Team understands the requirement in a certain way while estimating their work. The Product Owner has an entirely different idea of what easy to use mean. At the end of the Sprint, the Product Owner gets shocked at the level of ease of the use.

Many Teams and Product Owners struggle to use a certain kind of format or tool while defining their Product Backlog. However, they still go ahead and use that format and create meaningless and confusing requirements.

Teams new to Agile and Scrum, at times, still treat the Product Backlog in the older fashion. Teams forget to agree with the Product Owner where the Product Backlog will be stored, what will be the format, what tools and techniques they’ll use to edit and update the Product Backlog.

The Team and Product Owner should have a clear understanding where the Product Backlog is stored, what are the tools they are using to edit the Product Backlog, and how are they going to maintain the Product Backlog? Any changes made to these should be clearly communicated.

Scrum Master should work with the Team and the Product Owner so that they understand each others perspective.

The Scrum Master should work with the Team members to understand their viewpoint. She should work with them to help them communicate their viewpoint to the Product Owner in a way which is easier for the Product Owner to understand.