The Best Ways to Screw Up An Agile Project

Dave Snowden says that the human intelligence is especially based on utilizing patterns. “Our ability to link and blend patterns … gives us ability to adapt rapidly to changing context and critically to innovate”. Metaphors, patterns and stories are the most powerful tool of explanation, knowledge transfer and teaching. We have a limited capacity of information processing capability, but it is not the basis of our intelligence. One group of people make decisions purely based on information processing, and they are autistic. Whether you are communicating a feature in a software project, or a marketing vision of a large enterprise, the best way forward is to communicate it as a story or as a metaphor.

A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means . You may find best practices for example in agriculture, medical and manufacturing. Software development has its own best practices. Agility, continuous improvement, prioritization, active communication, design patterns, QA and CI/CD. Agile manifesto itself is a list of best practices. For seasoned expert these sound like a no-brainer. Well, how on earth the projects still fail?

While working as a Scrum Master, one realizes that while pursuing the well-known best practices, the same bad practices keep popping up again and again. These bad practices form a list of common pitfalls, which are called antipatterns or in Agile context ScrumBut. The antipatterns can be used as-is, but the most effective they are when used side by side with the best practices. Work towards the best practices. Work away from the anti-patterns.

ScrumBut

Sprint is too short or too long

• Too short Sprint (less than a week) increases the ratio of bureaucracy too high. Too long Sprint (a month or more) makes it hard to react on customer requests and the feedback loop becomes too long. 
• The best practice is to keep Sprint a bit on a short side, so the feedback and correction frequency stays fast. 
• Often is better

Sprint produces nothing working 

• Whatever was developed during the Sprint must be running in at least in the QA-environment at the end of the Sprint. 
• When software is not integrated, tested or deployed during the Sprint, work will overflow to the next Sprint. This means that it is impossible to change direction between the Sprints. One must first pay off the technical debt that has been created in a form of non-functional code. If nothing new works after the Sprint, the speed is 0.
• Often the "almost ready" features requires days of work to finish. You can speed up the completion of difficult tasks by having daily status checks. In the most critical situations the best way is to set up a "war room", where everybody concentrates only on finishing or fixing the single feature.
• The best practice is to finish earlier task before starting a new one.
• Stop starting and start finishing

No (real) Product Owner

• Product Owner prioritizes and clarifies. 
• The Product Owner provides a list of the most important Use Cases and a detailed description for each. Task of a Scrum Master is to tell if those features fit into the next Sprint. The less you start, the faster you finish. 
• A common malfunction is a customer who wants a software to be developed, but doesn't commit on the development process. Either there is no Product Owner, or the person is too busy/doesn't know domain/don't have an authority to make the decisions. In this situation the Scrum Master should coach the customer; Book a weekly meeting with the customer representative where the roadmap is being clarified and broken down into detailed tasks. 
• The best practice is for the Product Owner to have a detailed plan for next few Sprints.
• Task of a Product Owner is to maximize the value of the Agile team

Requirements are not communicated 

• A big up-front requirement specification helps nobody.
• Use Cases must be communicated two-way between Product Owner and the development team, fairly close before the development work. 
• The development should never be based only on a document. This will always cause the first version of software come out as unsatisfactory. It is much faster to clarify the details over a telco, than to code-test-integrate for weeks and to find out that the req spec wasn't top notch. 
• Coding a non-communicated requirement creates useless technical debt.
• The best practice is to have a clear and shared plan for the next few Sprints

No estimates

• Prioritization forces to have important discussions regarding the content and their importance. What user group to serve first? Non functional or functional first? New features or regulations? The common symptom of "no estimates" is that the Sprints produces nothing functional. 
• When the Use Cases have estimates, it is easier to prioritize and plan their development. It is also easier to identify the cases, which needs to be divided into more fine-grained Use Cases. Estimates are created semi-automatically, when the requirements are communicated to the team. When the Product Owner clarifies the Use Case and the team divides it into technical tasks, the estimates will emerge. Estimates will also teach about the team velocity.
• The best practice is to have a clear and shared plan for the next few Sprints

No prioritization

• No prioritization usually leads to starting too many Use Cases. This leads to Sprints that produces nothing.
• The best practice is to have the product backlog prioritized for a couple of the next Sprints. Product Owner, Scrum Master or the Architect should be fairly easy to explain the Use Cases of the next few Sprints.
• The best practice is to start nothing new before something finishes AND then start the highest priority task.
• Less is faster

No feedback

• Each Sprint should provide the team feedback. Customer gets the demo. Team gets the retrospect. Each Sprint is a step towards the better practices. One aspect are the project management tools with their analyses and reports.
• The best practice is to produce a functional demo and have a Sprint Retrospect. Repeat, the best practice is to have a retrospect after every Sprint.
• Reflect regularly

Inefficient individual

• Best way forward is to support or coach the inefficient team member. Usually people are not lazy but too busy. Mentoring and coaching are good ways forward.
• The best practice is for everyone to keep developing and improving. 
• Each team member must allocate time for self development

Inefficient team

• Team must be able to self-organize. Team members must be able for individual work, but the more importantly they must be able to work as a team. Shared ways and common rules. Cherry picking when choosing tasks, coding too low or high quality, forgetting the common rules etc. are signs of a hot-shot not able for teamwork.
• Team must allocate time for team development 

Doing the right things at the right time

Agility means doing the right decisions at the right moment. Traditional management models are more interested of doing things right. This leads to inside-out way of thinking. "We have a CMMi5 level quality standards". And still customer gets no additional value. Such a management creates tons of additional bureaucracy without creating much useful. Agile development advances with the best possible speed towards the best possible direction. Speed and direction are revised constantly when new information and feedback emerges. In sports one improves agility by doing neuromuscular exercises in a well rested condition. Same goes with knowledge work. Stress, fatigue and haste kills the agility; Work becomes stiff and laborious. W. E. Deming stated that 95% of performance issues is caused by the system itself and only 5% is caused by the people. Even talented people will fail, if the system does not give them room and freedom to prosper. Organize outside-in. Customer first.

Reference

Exploring ScrumBut—An empirical study of Scrum anti-patterns

This text was originally posted on 24th of of September 2018 at https://gofore.com/the-best-ways-to-screw-up-an-agile-project/