If you are an initiator:
1. Do not make the mistake of saying "We do not need project managers" and "SCRUM Masters are there to replace them".
2. Do not bring in a critical project to showcase benefits of SCRUM. Odds for gaining buy-in are always remote. It will be relegated to a one time wonder or considered an extreme measure. In critical projects, only people and results are spoken well, not the process or the way it was done. So never pick a critical or riskier project for SCRUM adoption. You are never going to get it past this one project.
3. SCRUM is meant for projects where details can evolve, but not the requirements, design or end solution. Do not make the mistake of saying "Since we are following Agile, you can keep giving new requirements in every Sprint". In SCRUM there is a need for Project/Product vision, define technologies, architecture, have a blueprint ready and all requirements planned for sprints in advance. It is only the details that can evolve, not the requirements. NOTE that evolving requirements projects will fail neverthless if it is SCRUM or not.
4. Sprints are not discrete events. They need to be continous. One of the anti patterns of SCRUM initiation is to conduct a sprint or couple of sprints, then evaluate that it is not working. Or pace out time gap between 2 Sprints. As with 10,000 hour rule, you need minimum of 10 Sprints or roughly 30 weeks to evaluate goodness of SCRUM and it needs to be analogous.
5. Reducing Retrospective to a paper process and not learning from it: I renamed them as "Refreshpectives" in my implementation. Somehow, to me, retrospective conveys meaning of just analysis and historical value. Refreshpective to me gives more meaning that you refresh what happenned and DONT REPEAT what was not correct. SCRUMs or subsequent Sprints suffer from mental blocks and tunnel visioning if Refreshpectives are not conducted in open environment and learnings are not taken ahead.
6. Managers - Please dont delegate your tasks in name of Agile. Reporting, task allocation, project planning, risk planning, mitigation, margins, allocation are all still your job- your deliverables. A SCRUM Master and SCRUM teams can only help you in thought process and assist in giving inputs to performing the role. My first SCRUM implementation sufferred when manager went hands free of the responsibilities and retained more of an administrative role only. SCRUM Masters are hands on and are quick in tuning velocity needs to meet plans. Treat SCRUM Masters as navigators (Velocity Managers) and SCRUM teams are drivers (taking you to the destination). The project charter still is your responsibility, dear Manager.
To Developers:
1. Understand that you should now think modular. No longer quick codes that handle a job piece as stand alone program are going to work. While thinking, ensure you follow a modular structure. Think what pieces could be converted as a lib file, what could get into config file, what needs to be a third party extension, how you would create hooks, interfaces to move them further and how you could split the source code into multiple files in src folder.
2. Make sure you always make provision for 35% effect. 35% of your code will be tranformed - either scrapped or rewritten or extended or reused. Think and Design every code for this 35% rule. And this is critical to success of Sprints.
3. Estimate time including scrap value. This is why Sprints and SCRUM estimations are good. Since they are done by team members who are going to work, you can factor in time to experiement with your ideas for some time.
4. Think Design first. Papers and Pencils are still the best form to release creativity. Agile, atleast in SCRUM context doesn't mean you jump in to code directly. In fact, it is opposite to this thinking sense. Design, Paper craft your story, divide and define your tasks and then take up finishing a user story.
5. Do not assume or expect Product Owners to be techies. In fact as a product owner, the job is to define the vision, goal and the working way for a user. You, as a developer needs to help product owner visualize how it will look at end. Not the other way around.
6. Escalate. SCRUM Masters and Product Owners and even your peers are humans. They are bound to make errors. Own the stand up meeting room to yourself. Make sure you articulate the allocated story well. Ask your peers for impacts in their code. Check if there are dependencies. I have seen 2 kinds of stand up - One where SCRUM Master speaks most of time. Another where designers and developers speak their mind. You can guess which would be the most fun.
To Onlookers:
1. Support SCRUM, even if you dont understand it. You are making the environment more greener. ;)
2. Read Agile Manifesto.
3. Reflect and embrace change as constant. Controls and Measures no longer work. Measure only what is done, not fit measurement to what was designed.
4. Visualize: Figure out the ways how SCRUM would have tackled your problem. Visualizing SCRUM implementation or for that matter any process, will make you more resilient to make the transition against heavy odds.
