Try to be good at Scrum.

How many times have you heard “Scrum does not work”? Not just Scrum but for any Agile methodologies that got picked up from the Methodologies store, applied blindly like an old school Project Management prescriptive process and expecting a result just because you have been following some ceremonies.

Well, you ll be surprised to know that it does not work this way! You’ll get a certain level of frustration coming exactly from this kind of approach. Clarity on how and what to achieve might drop, frustration in the team increase and confidence will take a hit, your delivery deadlines and your quality can be seriously affected, without mention that your team will lose commitment. Your move to Scrum methodology failed, you abandoned your waterfall approach and eventually, your are left with a undefined mix of ceremonies and process meaningless. A tragedy!

We need a Coach!

The Scrum Master or whoever function as an agile coach should be the guardian of the team, the one that will help to preserve team consistency, deliverable quality, promoting improvement iterations without interfering or imposing his authority. The good old way to define it is a Leading servant. Possibly ,someone, that if has worked well enough would make himself redundant in the role and leave behind a team that is self-functioning. Overall we cannot forget that Scrum, like the Agile Manifesto, was made by Engineers for Engineers. But what happen if you have no Scrum Master or just a Project Manager ? The answer is that the team needs to step up/in and ensure the team is functioning as we all expect. The idea is that everybody need to look into the team wellbeing, proactively support the change or safe guard the quality process the team built or want to build, each member of the team can be the SM, did we not say we need to be cross functional ?

Few Tips.

1. The Methodology is not a top down decision. Teams work differently based on different projects/needs. Sometimes the focus can be on trying to keep a very high through-output of small tasks/features, not necessarily linked and you might go for a more Lean/Kanban choice. Some other times the team is driven by a PO with a clear vision on what the goals are, where velocity is a key value, and iteration over delivering small increments of product is essential. The point is, Agile coaches should suggest a way to go based on how the team works and what they want to achieve. Remember Agile is an engineering way of work for Developers not a PM tool that replaces other practices such as ITL or Prince2.
2. Ceremonies cannot be executed blindly, each one of them serves a purpose. They are not tools to control a team,or adjust the delivery. Ceremonies serve the team to work better, to deliver incremental bits of the product at the highest quality standards in the most efficient way. The Daily Scrum for example. Is not meant to be used for checking if anyone has anything to do. Should be used to realise how close you are getting to your goal/increment. Do not walk the people … “Angelo what have you done yesterday what are you going to do today ….” that is not much of help really. My Daily Scrum conversation might or might not happen based on what there is on the board. The board is the point of truth, not the developer. The developer might be idle because WIP or helping/pairing with someone else or doing something not related to the sprint. If your concern is to keep people busy and control what they are doing, well Scrum is not for you. Remember Walk the board, not the People. Generally discuss with the team why we are doing it and what we want to get from it. The team might have some ideas or concerns. Still keep in mind to try following the prescribed best practices. In that case the SM recall the team to be disciplined.
3. The team is the mastermind of any decision. There is not a role that can overturn team decisions on how to work internally, nor the Scrum Master or a tech lead.. Scrum teams are small, or at least should be, this means the whole team can participate and contribute at every single stage of this methodology. There is not representative members that will decide for example who can refine and plan tickets. The decision on what to do is a team concern. The team could actually reject PO vision and do not accept what to do in the next sprint. If we deprivate the team of operating in autonomy and contribute equally to such decisions and ceremonies the conseguenze could be easily a lack of commitment of the product success, at the end the team decisions wont impact the product anymore, so why bother. On the other hand, being part of a Scrum Team means being proactive. We are part of a complex chain of production where each person decides how the machine moves. This means constantly questioning and contributing. Refine work, looking outside your small box and try to operate in a cross-functional way. The Scrum team is cross-functional by definition. Is not based on sequential phases and states. Team members are active in every single stage of the software life cycle. Accept/Reject/Refine work, plan it, develop it , test it, deliver it, demo it. There is not necessarily the BA that write the AC, or the QA that will test your work. We should all be able to cover these functions in a scrum team. The Scrum Master needs to favour this and motivate the team in that direction, not just be concerned to to delivery in time.
4. Tools. Thinking that a tool used by a sales team can fit engineering needs is just insane. This is valid from the right laptop spec to what communication tool should be used. Agile and Tools are essential, moreover in a WFH era. Interaction should be facilitated. Some tools serve this purpose better than others. We cannot compare Skype with Slack. Integration with the development tools, with the project environment makes developer life easier and facilitates daily interaction with others in ways other parts of the company do not do. Interaction with software for PR’s CI/CD helps to smooth conversations, interact faster and have a positive impact on the team morale and collect fast feedback from the customers. Electronic boards, that are not just tracking systems. Kanban/Scrum boards, should be organised by the team in a look and feel that matches the workflow. Continuous Integration for example is not just Dev/Ops operation, is at the core of any agile team. CI in fact serves to: minimize the duration and effort required by each integration episode and to deliver a product version suitable for release at any moment. As Martin Fowler mention:

anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week.

This was a short generalist overview of a very common pitfalls we all make in our organisations and projects. This generates miss trust towards the Agile World when actually the problem lay with the agile practitioners: not well informed or prepared . Ad Maiora!