We, for ages have been attending a lot of workshops, trainings, getting coached, reading a lot of material on the internet, wherein all of them are providing guidance on how to implement / adopt the right and the correct practices of agile / scrum / Kanban.
My blog today is a high level summary (not all points) of anti-patterns for everything that the world is preaching, teaching and more importantly NOT IMPLEMENTING
My guidance would help all the organization and respective managers to know and learn how to mess and manufacture a disaster for their agile ways of working.
We all know 3 important roles in Agile or should I say Scrum (in specific) – We shall today take the most neglected role of Agile – “THE PRODUCT OWNER”
Off-late watching and experiencing the world and the behavior with the product owner, I have become more educated on ideas, thoughts and tips to mess around with the role of Product owner and thereby understand methods and ways in which the value of Agile adoption goes / can go down the drain.
Fasten your seat belts, Here we go …
TIP # 1
Never Empower your Product Owner: Giving power for decision making to a product owner could be injurious to the health and wealth of the Line Manager / Sr. Manager. Always tell the PO what to do, how to do, ask them to document each backlog item with every possible scenario (in the same PBI – even though the PBI would now qualify to be a large feature or an EPIC by itself).
Never give liberty to the PO to decide how to maximize the value of the product, the order of the product backlog items, making their only job is to do documentation of the requirements in complete fashion / manner as we desire, they should not be able to move an inch without our approvals. We are more interested that our PO act and behave as SCRIBES … rather than as Product Owners.
If you do what I am recommending here … Bingo you have achieved Level 1 Maturity of Messing up with the agile ways of working …
TIP # 2
Have your PO also double up as Scrum Master: Well every organization that I know is always short of right resources and talent. If one FTE can double up and do the job of two, nothing like it – a bird in hand is worth two in the bush. It would always help the team as they know they have to look up to one person only and it saves a few dollars of the table (nothing like saving money), it prevents challenges and issues or managing the expectations of 2 people, conflicts are reduced (as we have 1 person only – never heard of a single person is having conflict with themselves).
If you implement and adopt this approach as recommended here … Bravado – you have achieved messing up with Scrum Guide itself … and that deserves kudos and a bravery award to those who take, implement such decisions.
TIP # 3
Have a Proxy Product Owner (who is powerless): Our true North Star “THE PRODUCT OWNER” is across the oceans and in those time zones, that is difficult for any sane person to be wake and sit late at nights and interact with the team (when the team is working). Every problem has a solution and this case it would be to create a replica of the actual product owner in our own location and call them as Proxy PO’s (well we have just introduced a new role in Scrum – Who cares of the Scrum Guide).
Using a Proxy PO is an attempt to superficially treat a systemic issue and push the actual problem below the carpet. One should never allow the Proxy PO to take decisions, they are like glorified Postman / Post Woman here … they only have to take orders from one side of the coin and communicate (with gaps of course) to the other side (aka Development team).
In case you implement and adopt this approach as given above … You have installed insecurity, confusion which effectively breaks down communication in Agile, well who cares for Agile Manifesto statement… Individuals and Interactions over Processes and Tools
TIP # 4
The Partial Product Owner (Allocated to more than 2 teams): One nice way to making our product owners ineffective is to give them multiple products / projects to take care of … So that more than 50% of their time will be spent in doing Scrum events (Sprint planning, Sprint Reviews, Retrospectives and so on …) across all the teams, they should never get time to do quality work on the Product Backlog, think about prioritization and ordering of PBI’s or discussing important elements with relevant stakeholders or end-users. Always work with the approach that – we shall cross the bridge when we come to it.
If we have created such situation, we are at the prime of not messing one but multiple projects, we have actually graduated in our approach and thought process and we deserve a pat on our back
TIP # 5
The Over worked Product Owner (working for more than 14 hrs / day): Working in normal times would get you a rating of 3/5 in your appraisal system, which states – Meets Expectations. These days all organizations need people who would work beyond the normal hours. We have unrealistic deadlines and commitments. Management and Sales folks make an unachievable commitment and then the development team (along with the PO) has to deliver … in order to do this we have to work beyond a normal timeline or cut corners – we end up doing both.
This results in Technical Debt, Poor quality of product and services, dis-satisfied team and unhappy customers – but guess what – we are hitting the clock more harder than before …
If your products / projects have managed to have this situation, then we should be proud of our achievements, any-which ways client and management do not understand the concept of Technical Debt (so it is cool and fine).
Conclusion:
I believe these 5 tips are great source of Anti-Patterns (should I say – Industry ways of working – Anti Pattern would sound rude). If you want Agile to be messed up, use these ideas (they are free and no copy right issues – you can take and update them to be become more fancier).
Nothing that I have said today, is new or rubbish – it is actually practiced in our world by all the agilists – who have great certificates and knowledge, but we buckle under the pressure of having a job, regular income, management, peer pressure and so on …
For ages I have failed to understand why management wants to spend money and hard dollars and still not receive value … well the answer lies that nobody wants to implement AGILE. It is just a buzz word in the system.
If you believe in doing the things right and in the right approach, follow the reverse of all the tips given here … you would notice a more productive, safe, guilt free implementation of Agile.
Try for the true Agile for 4-6 months – do it in the true spirit of the game … if you still do not see results … go back to your old ways – nobody would stop you (anyways nobody is stopping you today also). I would be coming out with such blogs as a series on all roles of Agile / Scrum and then move to events and outputs.
agilescrumworld 