One WEEK Sprint
Ownership and Accountability will define the success of your project. Engage your dev team into decision making. The velocity and speed will follow.
When we look at the object located far far away it seems they are standing still. (Sunset) In reality, the Earth is circling around the sun with a great speed of 108000 Km/h. Your development velocity might also have a massive difference in the perception from the dev team and views of the management.
One Week Sprint helps to bring synergy and understanding in the software development process. Take the red pill!
The very first principle of Agile Development is related to the team.
Unless you start a new startup from scratch, most of dev team already works in an established organization with a set of rules and practices which we commonly name engineering culture. So any cultural change will be taken with hostility and thus fail at the beginning. So the best option to adopt changes is by bringing them into smaller groups. Famous 2 Pizza rules will need to be shared into smaller slices. 1 PIZZA rule is something I recommend. Start with splitting your TEAM or SQUAD into smaller, agile tactical units. 2 Dev Team is a magical formula. (Let the team decide who wants to be in the team with whom). The more individual decision you leave to the people the better outcome you will get. Once we move to Tech Planning. You will be surprised how smooth the process flows with only 2 Dev in a team.1. Individuals and Interactions Over Processes and Tools The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.
Kanban is the most suitable framework to implement in agile software development. It requires real-time communication and full transparency of work. Work units (tickets, epics, user stories) are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
Ownership and Accountability will define the success of your project. Engage your dev team into decision making. The velocity and speed will follow.
Kanban is the most suitable framework to implement in agile software development. It requires real-time communication and full transparency of work. Work units (tickets, epics, user stories) are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
Ownership and Accountability will define the success of your project. Engage your dev team into decision making. The velocity and speed will follow. Kanban is the most suitable framework to implement in agile software development. It requires real-time communication and full transparency of work. Work units (tickets, epics, user stories) are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
Perhaps the most challenging roadblock of the one week sprint. In more or less traditional software development tech planning happened after the board was groomed and sprint undergoes the first steps. Developer look at each user story assigned in the sprint to discuss how technically the task should be solved. In One Week Sprint you are doing Board Grooming and Tech Planning in one go. The biggest pre-condition comes from product planning of the last sprint. Your product team needs to logically connect already delivered work with planned tickets so that your development undergoes one logical working flow. I suggest breaking user's stories into bigger epics and pulling those in the Tech Planning one by one based on market learnings. You may also learn after a few sprints that stuff you had in the backlog lost its relevance over time. Weekly Tech Planning allows you to engage your dev team into the decision and planning process. Make sure that your team decides what they will commit during the week. Once they pull work units into the "Sprint" column that's it, no more ad hoc changes. Treat this as a personal contract. Your team commits to a project and you lend them full support.
What if you have urgent changes? Ask yourself how urgent are they. Can this wait till the next week?
Each dev team is different but my experience shows that after a few "week Sprints" the planning accuracy becomes better. And your dev team will commit and fulfill commitment each time. The results are higher morale and team confidence which leads to higher complexity work they commit to doing each week and generally fun working environment.
Since you are doing short, agile sprints in an even shorter time than DEMO becomes your best health check body. Make sure your team can make an internal demo covering exactly the set of features or work units they have committed at tech. planning. Your DEMO should happen on staging or any other development environment you use in the company that is as close to the production environment as possible. Right after the DEMO and all Tests showing green lights the code should be immediately deployed to production. I know there are tons of opinions about not making deploys on Fridays. I have an opinion that there should be no difference in the day of the week if your internal processes are run predictably.
Make Internal Demo as enjoyable as possible for the team. At the end of the day, it's the only One Week Sprint ritual that allows team bragging for the accomplished work. Remember that join the company for the Vision but remain for the small wins they can have each week. Tech DEMO is one of those WINS your dev team is able to clock in.
Retro or Sprint Retrospective is the most important ceremony to integrate learnings into improvement loops. As described in the Scrum Guide, the Sprint Retrospective is an opportunity for the Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
One week sprint is too intensive for holding up Retro after each week of working. After several months of using this methodology, one per month seems to be a perfect time to hold Retros. Also, it makes it easy to schedule an event that repeats each month. And the team collect and reflect on the comments they raise during the Retro. We have been using two tools. Both seems to work equally good: Miro and most recently Team Retro. Both tools did the job of hosting remote meetings and collecting/voting on the pain points.
Depends on your team size. I recommend holding up Retro session in the work unit that was working independently in the week sprint mode. So don not invite other team members who were not involved in the week sprint. Only people working day-to-day in the working unit and week sprint should take part in the retro.
Moderation is quite important. Let someone neutral to moderate the Retro and make sure your mention action points form the last Retro to actually see if you making the progress.
Keeping track of each retro and leave a documented trace is important. Retro is a ceremony where action points will be turned in deeds.
Well organized backlog is a travel map for your journey to success. Keep it messy and you will get lost similar to a sailor without a compass. Since most of the ideas and requests are thrown in the backlog. Your PO has to groom the backlog quite regularly. Not only to keep it clean in organized but also by checking along with the business requirement. Not syncing the backlog with a business unit for a few weeks could lead to building stuff no one needs. Don't be afraid to delete and shuffle things around. The backlog is your chessboard to pick the right work units (user stories) and put them in technical planning. If you have too many tickets in your backlog and you are not able to break it down in the 3 consecutive week sprints it's a good sign to start cleaning your backlog and deleting ideas that don't bring a core value.
I have picked a parallax template to write this methodology for a reason. Parallax is a natural displacement or difference in the apparent position of an object viewed along two different lines of sight.
In a philosophic sense: an apparent change in the direction of an object, caused by a change in observational position that provides a new line of sight. The apparent displacement, or difference of position, of an object, as seen from two different stations, or points of view. So the velocity of your development team could be perceived with different speeds of execution from a different point of view.
Perhaps your team velocity is not that slow after all. Just change the position from which you measure the speed of development. One week sprint helping organizations changing this perception. Give it a try and I hope this helps your Business unit and Development find a perfect synergy building business together.