Scrum But – What are you doing wrong?
I’ve been a Scrummer for a while now. My first experience of Scrum was during my placement year, where I was a member of a Scrum But team. That isn’t necessarily a bad thing, in my experience, Scrum But teams aren’t formed out of a lack of understanding or will, but through the requirement to adapt to the current situation, one of the tenets at the heart of Scrum itself.
One of the reasons for becoming a Scrum But I have came across was the lack of understanding outside of the team, mainly in “I can only be bothered when it suits me” style stakeholders.
My first working of experience of Scrum came through a lecturer of mine, who was working closely with the company I was working for, acting as a consultant. The need for the implementation of a solid project methodology was apparent to everyone involved, when he began to mention a buzz word around the office. It wasn’t long until people from all walks of the facility would wander over to I.T team and ask what Scrum was, though also not long before they wandered off bored.
This made it ways upstairs (Literally, the board members were above us) and the decision was made to use said lecturer’s consultancy to introduce Scrum into the business. After spending a day sat in the boardroom making lego models in mini sprints (A car, A bus, A Boat and the Star Trek Enterprise) we had all the understanding we needed to run off and implement Scrum, though this became Scrum But quite quickly.
The team were all up for the process, and happy to receive it and the flexibility, trust and control it introduced, but the bigger picture often meant the scrum members would chair sprints alone, of backlogs of work would go weeks or even months without being touched, leaving periods of work where members of the Scrum team were not being utilised. This was my first experience of not only Scrum (For those first few weeks), but also Scrum But.
I’ve moved on since then. I’m currently leading the development of a bespoke system, as well as playing Scrum Master on multiple smaller projects, ensuring developers stay in control and on track across multiple projects at once, whilst also playing the role of developer. I love my role, although it contradicts one of the points I will make below, sometimes we are all guilty of a little Scrum But!
Common Scrum But Mistakes
The title of this post asks what you are doing wrong. Maybe you are doing something wrong, but it may be presumptuous of me to assume that because your team is using Scrum But, that you are making a mistake. Times change requirements change, as mere pixels of a grandeur scale we must adapt to the needs of those more important* (Loosely used) than us, and often that means breaking the process we love so much.
I’m not here to criticise or doubt that you’re are making the best decisions for your project.
Instead, I’m producing a list of common pitfalls of those using Scrum, potentially issues that can be fixed and reduce the difference between your/my Scrum But and the original tenets of Scrum.
Without further Ado, I present to you, A list.
- Scrum Master / Contributor
The Scrum Master is a shield, a firefighter or personal bodyguard. Their job is to watch the team, sometimes sitting idle, removing obstacles before they get the chance to stop the team from progressing. Taking on tasks can distract the Scrum Master from his/her duties.I must be honest and say this is the rule I Scrum But the most. I’m acting as Scrum Master, but on the largest of the current project’s I’m also a contributing team member. It’s working. I often stop my tasks to prevent issues that may affect the team, but the contribution works well and doesn’t impact the duties of Scrum Master, in my eyes at least.
- Failed Sprint Restarts
It’s not often a sprint is cancelled, in fact I’ve not had one cancelled yet on my current project, and we’re 6 months in. But when a Spring is cancelled, there will never be a perfect time to restart. Just get on with it.
- Dialy Scrum Run-Ons
Ok, of this I’m guilty of allowing to happen, on occasion. The daily sprint is a review of the day before and a plan for the day ahead. There should be no design or functionality discussion, we shouldn’t talk about films or anything outside of the three required questions: What did you do yesterday, What will you do today and Is there anything that may stand in your way? All other discussion can be held with only immediate stakeholders.
- Excessive Planning
This isn’t Waterfall Folks. We don’t need a two-month planning period, we just need a list of requirements to begin a project. The short feedback cycle keeps us up to date with ever changing requirements. Development can even be created in tangent with the creation of a Product Backlog.
- Assigning Tasks
You, as a developer, are brilliant. Every developers mind is a unique algorithm capable of solving mazes, in its own pattern. I have never assigned tasks to my team. I have made suggestions, when asked, but I would never tell them what to work on that day. We are seeking Motivation, free thought and interaction, not a forced labour camp. Stop it, Stop it no and reap the rewards.
- The Hero.
Scrum isn’t about a single person working 40 extra hours a week to deliver a project on time. Scrum is a team effort. It’s about building a team comfortable enough to share a late night pizza and game of poker on a Thursday night whilst stuck at the office, working towards the same goal. Scrum is about a single collective, a virtual being built from the combination of it’s parts. Everyone gets better, as do the solutions we produce. Stop the individual heroics and if there is a problem, fix it.
- Product Owner Doesn’t Show
Kind of a biggie, but unfortunately not a rare issue to hit Scrum teams. Whilst a Scrum Team is a self-managing entity, they shouldn’t be making the business decisions. The concept of allowing the developers to control the development means that the Product Owner can focus simply on the selling of their idea. The product owner is a team member, and should be involved at every step of the way.
We don’t allow interruptions. Should something critical arise, we cancel the Sprint, fix the issue and plan a new sprint to resume. The projects schedule can then be altered to account for the lost development time. Only two things change, Scope or Deadline.
- Back Seat Drivers
Sometimes it’s nice to have som advice, but any Team Member on any project must remember, advice is often outside of the scope of the problem domain. Things are easily missed by the “That’s easy, Just ….” answers from across the room or down in the corner. Accept help, accept advice, but pray caution to the wind when implementing any solution, Especially one you don’t fully understand. Don’t allow external entities to drive the motivation, ideas or path of a Scrum team. This is the biggest pitfall I think I could suggest.
- Team Organising Backlog
A key concept here is a Product Owner has an idea,and a Scrum Team builds it. At no point should the team dictate features and/or functionality, or the order in which it is produced. Nobody but the Product Owner and external stakeholders should hold the key to organising the product backlog, as it can fast be the difference between a happy boss, and your P45.
- Stretch Goals
Another common biggie, that happens far too often. In fact, I’ll be honest in saying I’ve been fighting to prevent this of late, with the introduction of Scrum across the wider development team at my current company. The team decides what work it will commit to within a Sprint. You need a degree of trust in a Scrum team for Scrum to work, but your Scrum developers know this, and will deliver their end of the bargain. But the more you criticise, and try and enforce deadlines or encroach on their time, the worse the end results will be.
- Focus on Tools
Scrum is an Agile methodology. We don’t care what the tool can do, we just want the process to work and people to understand said process. A white board, some sticky notes and a pen are good enough for this, digital tools can come later, they are not important.
Developers are smart, that’s how we got this job. To the point we tend to try and figure out a solution, often instead of asking. Especially outside of our domain. A Scrum Team must be sure not to make any assumptions about the constraints on any logic being created for a solution. The answers must be sought, through the correct channels, in order to utilise the business experience of those around the development team.
- Demo Failure
“Oh it didn;t work, I’ll fix that later”. Part of the Scrum Proces is to prepare for the sprint reviews and retrospective. This is included within the Sprint. Don’t show up without a working demo, or the PO will soon get frustrated and will view this as a lack of progress.
- Not Completing
Not hitting that state of done within the sprint timeline. Sometimes, this is impossible to combat, and as a Scrum Team gains more experience of the domain and their own skill set, time predictions will get better. Sometimes, it just takes a little patience to prevent some Scrum But.
Everything created in a sprint must be potentially shippable. New work cannot knock-out old work, or allow for half finished scaffolding to be constructed in a “To be Completed” manner. A wire framed solution is not a solution, make sure you understand the definition of Done within your team.
- Distributed Team Members
Can cause issues within Scrum. As Scrummers, we like Transparency and Communication, but also that familiar feeling we get at 8am of sitting in the same room with the same people, answering three simple questions. This becomes more difficult when team members are distributed. Sometimes unavoidable, but can impact progress.
- Micro Management
No room for this in Scrum. The Scrum Master must make sure the team manages it’s own workload, and must resist all temptation to get involved or give instructions.
- Changing Roles
Never good with any methodology, but having team members change roles throughout a Scrum Team forces a restart to the processes involved, meaning a waste of a certain level of investment.
- None-Scrum Roles
Oh, it happens. A Scrum Team requires only a Product Owner, Scrum Master and Team Members. This is where it stops.
- Scrum Master Not Present
At all times, the Scrum Master should be with the Team, after all he is a member of it. Moving this shield away from the team allows for distractions, or other workloads to sneak in on the side.
Imposed Deadline, Scope & Resources
This Scrum But pitfall gets a section of it’s very own.
There are three corners to a project, the Scope (Requirements) of the project, the Resources available and the Deadline. Each of these corners is a variable, and they move in a locked combination. When one is expanded the away from the centre, the others are moved towards the centre. Now, as a Triumvirate, only one necessarily must most towards the centre for another to be expanded, but that depends on how you drag the corner.
If the deadline moves up, Scope must decrease, or resources available to the project must increase. However, these don’t move on par. Reducing scope is less costly than increasing resources, due to the loss to training and getting a new team member into the projects mindset.
If the scope increases, either the Deadline or the Resources move. Again, this is disproportionate, as any new resource must first get into the flow of things.
I’ve seen deadlines move up, without scope or resources changing, and all that happens is the deadline is missed and everybody gets pissed off. Not just the decision makers and stakeholders, but the team members themselves. The last thing they want is to get in trouble for missing an unrealistic deadline outside of their control. You will lose your team this way.
No unrealistic impositions can be constrained against a Scrum Team, with the boundaries of realism, in this case, being determined by the team and not the stakeholders. There is al evel of negotiation required, but any Product Owner, Stakeholder, Scrum Master or Team Member must be aware that if one moves, so must the other two.
Scrum is about Agility. About reacting to the ever changing needs of a problem domain, and providing the solution in a continuous fashion. It is not about placing higher demands on team members and expecting greater rewards. It is a realistic approach to the management of a project as required by all parties involved, and not just what is expected from those at the top. Scrum works, as it brings the expectations of all concerned into line, a level playing field from which to plan future projects, and over time, satisfaction levels amongst the team, which includes Product Owners and Stakeholders, increases.
The biggest issue facing Scrum Masters is levelling that playing field and narrowing the Scrum But to as almost Scrum as can be achieved given the working environment. In doing so, we can achieve an understanding between the entire team or hopefully company, over a much smaller period of time.