Scrum horrorscopes for sprint 7, 2015
It is with sadness that we have followed the discussions on predictability in software development, as well as the raging Twitter debates on #NoEstimates. On one hand, Scrum practitioners are much aware of the difficulties inherent in estimating and predicting, but on the other hand we are all drawn towards the perceived certainty in a well-defined plan.
However, since software development is a complex-responsive system, it is clear to any thinking and knowledgeable individual that changes in the constellations will for sure affect the events happening to a Scrum team*. The experienced coaches and trainers from agile42 have gazed into their crystal balls (and in the case of Niels, the bowels of a grilled chicken) and drawn up the appropriate horrorscopes. Just be sure to choose the right one.
Your role as supportive mentor to the rest of your team may feel uncomfortable at times, but it gives you a wonderful perspective on your workmates that no one else has. You are beginning to appreciate the hidden power of “coaching” people around. The force is with you, young Scrum Master. But you are not a coach… yet.
The immediate future does indeed look rosy and this sprint might already go better than you anticipated. However, dark clouds are spreading on the horizon as the next release draws nearer, and you must think carefully about how to make the team deliver everything on time. At the same time, stakeholders are growing more adamant in their demands for increased velocity. Look for creative synergies!
Resist the urge to straighten out the burndown, as it is unlikely that anybody will actually look at it much this sprint.
Life is a fluid experience, especially this upcoming sprint. Things keep changing, and usually you’re ready to roll with the punches. However, a situation you thought had been resolved rears its ugly head. The relationship with some stakeholders may become bumpy towards the end of the sprint.
In hindsight it would have been a good idea to consolidate the views of the stakeholders into one common product vision at the beginning of the project. As the damage is already done, creating one now is likely to be a waste of time.
The upcoming changes may require some painful adjustments on your part, and you are reluctant to seek help from the team. Although you may be able to talk them around in mid sprint, you might also have considered just handing them some brand new stories in the next sprint planning. Both options are open — but only one is the right choice, so pick carefully!
People may bring up the question of product quality again, so make sure to keep a symbolic reservation for bugfixing in the sprint. But only symbolic, mind you, as the stakeholders really want to see the new features you promised earlier.
Towards the end of the sprint the developers may raise this recurring question of technical debt. The situation is again very easy to resolve, as you can just defer to the stakeholder demands for more features.
Estimates you gave at beginning of the project will magically become commitments during this or next sprint. To make matters worse, the estimation jokes you threw earlier were duly noted by the Project Manager who will now divide all numbers by three.
In this sprint, you will also finally realize the full WTFness of the code base, which seems to have been designed using the “onion model”. The closer you look, the more you feel like crying.
The architecture change proposal that would restore a semblance of sanity to the product will be turned down by the System Architect when he gets around to reading it in early May. Without a version control system and proper automated tests, rewinding the code base to comply with the Architecture Description will be… interesting. Resolving the situation requires thinking outof thebox, as well as polishing your CVs.
Things may seem rather chaotic this sprint as you run around juggling all your projects. Don’t make any commitments now, as you can’t fully see the implications of what you might be agreeing to. In fact, don’t even make any estimates.
The company seems to employ three managers for every developer, which can be a chore sometimes. If working with others seems to require too much synchronization and diplomacy, just be frank about what you think about other people’s work. They will appreciate it later. Also fly solo whenever you see an opportunity for it.
If you have hidden resources, they may not survive this sprint. More specifically, the unlisted old desktop that serves as the development hub for the team is likely to be discovered by IT and its MAC address blocked “for security reasons”. Just lie low for about three weeks until Marketing accidentally draws the attention of IT by exceeding their disk quota, then silently change the MAC address.
You will meet a dark stranger with a business proposal. In fact, you will most likely receive seven or eight proposals this week, all from Nigeria. Do not deign to reply unless the sum offered is at least 17 million USD.
Your quest to find the right aglee…? eagley…? uh, agile scaling method requires high levels of subtlety, diplomacy and expertise — all things that you excel at. Just invite every sales representative to the same meeting and let them duke it out. But don’t hurry to pick the winner. While you certainly need to show stockholders that you have a strategy around this ugly…? achoo…? um, agile thing, remember that your own compensation plan may eventually be at stake! Ask your best strategy analysts to form a committee and study their quarterly reports with care.
Other than that, interesting opportunities are cropping up. Your new blonde secretary went out for dinner last week but only with her sister, and she is not in fact seeing anyone at the moment. Also, a near relative who knows something about computers is going to be looking for a job in the near future, so you may want to start finding faults in one of the Vice Presidents who is currently doing something with computers.
You appear as if you’re open to other people’s ideas now, but chances are you have already decided your course of action. Make a point of listening, but stay firm. Don’t take too much stress if you are dragged into uncomfortable discussions. Instead of trying to emerge victorious in an argument as usual, just smile and walk away.
Despite initial misgivings, it is likely that you will win the next performance review round. Your boss is feeling strong peer pressure, but agrees with you in heart. After all, you know the product better than anybody else in the company, and cannot be held responsible when developers misunderstand things. The coupe de grace would be to get KPIs for enforcing system architecture compliance into the next round.
You have cleared many a difficult decision and quite understandably feel like hibernating for a month. But keep your eyes open, and an opportunity for diving into action will present itself! This is a fantastic time to be a Project Manager, as you have a chance to accomplish much more than you expect if you only stay focused on your goals (and the CEO on his new secretary).
If the defect situation becomes overwhelming, downprioritize some bugs. You can always up-prioritize them again later.
As to the matter of making the deadlines, hang on for as long as possible before letting everyone know that you will not deliver on time. The early estimates you demanded from the developers will come in handy now.
Your friends give you differing advice on how to extend your collection of certificates or whether, indeed, to just rest on your laurels. In the end however, a certificate on the wall is better than ten in the bush, and people with both PMI and Agile certificates seem to be in high demand. Choose wisely!
The product quality responsibility weighs heavily on your shoulders. During sleepless nights, you may be pondering the wisdom of taking responsibility for something you cannot actually do anything about. Discussing your concerns with a colleague is unwise, as it could serve to make you seem incompetent or weak in the eyes of the whole unit.
There is a growing risk that you will be facing an increased workload towards the end of the sprint. In fact you will be testing all stories on the last days of the sprint. In the retrospective the developers on the team will make sure to point out that unlike you, they completed most of their tasks for the sprint.
Until now, you have marshalled your strength and dug down into your work in an admirable way. But during this sprint, your feelings about the situation should begin to shift, reflecting a change in the cosmic energy. If you could somehow encourage the developers to check their own work, there might be room for real testing and the opportunity to provide stakeholders with valuable information about the product. However, your manager firmly believes that developers are not to be trusted with testing their own code, so that’s that.
Managing a project can be like a dance: one leads while the others follow. Right now one of the stakeholders seem to be in the middle of a political tango (or possibly the Swan Lake, it’s too early to say). Your goal should be to approach this group, find synergies, align your strategies and streamline the process, but in order to do that you may have to let them lead for a while.
While you can convince others that your position is a solid one, you’re not going to persuade anyone with only words this sprint. Language is shallow and just won’t carry across your deep conviction. Beauty is currently the major motivating force, so take your time and act only when your aesthetic sense says yes. Do make sure to save every email and make notes of every phone call, in case you need to “clarify” things later.
Your best allies are those who think the same way you do — people who are smart, inventive, creative, nimble and flexible! Working together you can achieve anything! With a little brainstorming, what previously seemed like a fairly big issue turns out to be entirely doable, and getting it rolling is a lot of fun.
The System Architect may try to prevent you from going forward, but will back down if you don’t take any notice. You will find a true friend in the UX designer, who appreciates the possibility of changing the color and position of the user interface elements every two weeks.
On the other hand, your relationship with the developers will cool down even further after you update the acceptance criteria of the stories the team selected for the sprint. But remember that the development teams are supposed to be agile. If this doesn’t mean the ability to adapt to change, then what does it mean?
The upcoming sprints will be a disaster, and your future looks correspondingly bright! All the meetings and overhead in the agileschmagile approach has prevented you from doing real work, and you will now have all the chances to put blame where it belongs. Before long you will be sitting in peace in your cubicle again, your tasks comfortably 90% done and only held back by a few pesky technical problems that should be resolved within a couple of days, tops.
However, one of the most important skills you still need to master is knowing when to ask for help. It’s important to not immediately call out to friends or coworkers if you feel like you’re in over your head. Only when details pile up and obscure your route to success should you start compiling a list of books to read, or think about participating in some training. The farther you can go on your own, the better! After all, you are the specialist.
You’re tempted to exceed your role description in order to support your colleagues.
This little self-indulgence of adding a field here and optimizing a table there would normally be fine, except you’ll probably realize that such lighthearted distractions are not necessarily bringing you towards your professional goals. Besides, after they caused the database seizure last week and then tried to shift the blame on you, you are simply not in the mood to help out.
You may now be seeking ways of preventing unauthorized access to the database. However, you won’t get what you want if you push too hard. It takes a delicate touch to deploy your intentions without stirring up unnecessary resistance. Silently retract all “unnecessary” access to the database, and talk to the Product Owner to add a comprehensive administration interface to the project instead. Although you have had your differences in the past, the System Architect appreciates your method of defining each table dynamically in another table — sheer genius! — and will be happy to sign off your design.
Keep your chin up and if anyone needs anything, just pretend to be really busy with finalizing the full data structures for the upcoming project. Don’t be surprised if this makes some people uncomfortable, but stick to your guns and don’t be intimidated. After all, the database is the foundation of every nontrivial project, and they will learn to appreciate the importance of proper database administration.
* Because of quantum.
** Yes, there are two tauruses... taurii... tauruseses... whatever. See it as an Easter egg.