Below is a document I wrote with suggestions for how we can potentially change our process to promote more reliable, quality and friendly processes. It is basically a derivative of scrum. Thought I’d share on my blog.
Enjoy!
———————————————————————————————–
The below is a set of suggestions for how we can change our development process to be more reliable both in terms of estimating completion dates and code quality.
Development Process
Ideas For A More Reliable Process
Desired Outcomes
There are three outcomes the below suggestions are intended to support.
1. Reliability of Delivery Estimates
2. Increased Code Quality
3. Increased Team Morale And Buy In
Reliability of Delivery Estimates:
First we hope to change our process to make our delivery of work more predictable. We hope the below changes allow us with more accuracy to communicate to stakeholders how long a feature will take to be complete and when it is possible for us to complete it given workload and priorities at the time the feature is requested.
Increasing Code Quality:
The changes suggested below are also intended to increase the quality of our work. By increasing code quality we mean decreasing the amount of defects identified in our code, and identifying defects sooner in our process.
Increasing Team Morale and Buy In:
The suggestions below will address increasing developer ownership and collaboration with the hope of increasing the morale of our work environment and increasing developer’s sense of ownership over the whole work product.
Suggestions
Split Group into Smaller Teams:
We should split our group into smaller teams that have resources that can work on layers of the products the team works on. This means each team should have at least one person who is capable of doing SQL work if their products interacts with a database, at least one person who can do MVVM work if their product has a web front end, and at least one person who can work on services if their products interacts with services. Teams should not be too large as large teams tend to break down into smaller informal teams anyway.
We are suggesting we create three development teams of five in the web group. Each team would consist of one senior level developer, two mid our above level developers, a resource to act as a proxy for a business analyst role and resource to act as a proxy quality analyst. One person on the team, either the senior developer or business analyst proxy or quality proxy, will also act as the team administrator. The team administrator will be in charge of organizing meetings and managing the team’s actionable backlog.
The teams should decide on a name for their team, this adds in creating team buy in.
Sprint And Story Management:
A story will only be worked on if it is in a sprint. Issue Manager should be changed so that Sprints are their own field. When a story is scheduled to be released is important information and should be managed separately from when it is worked on. If a story is required in a certain release then it should be included in a Sprint that happens before or during that release.
story’s will be assigned to only a team. Developers will track their time in the story against whatever item they are working on, but actual task management will be up to the team itself. It will not be necessary that individual developers are fully loaded via story, only that the team has taken on an appropriate amount of work for the sprint based on its velocity and accommodation for expected support work.
To increase buy in and participation from the group sprints can be named differently than releases. The whole group can decide a naming paradigm for sprints each year and then the year can be cut into those sprints. For instance the group could decide that cartoon characters will be sprint names for 2015. The first sprint of the year will be a cartoon character that starts with A, the next B and each sprint is named for the entire year.
Estimated Hours as Velocity: Break Estimates Out Into Initial Estimate and Actual Work Hours:
When a story is estimated and assigned for work, allow the original estimate to remain always unchanged. Allow the actual work to be the sum of all the developers hours logged to the story, but do not allow the original estimate to be updated.
Use the original estimate number as a way of measuring feature throughput. Allow the velocity of a team to be the number of estimated hours that it completed in sprint. The estimate hours don’t have to have any correlation to the actual amount of work done. The idea is to create a metric, estimated hours, that we can track and use as a means of understanding how much work a team can likely complete in a sprint.
Allowing estimated hours to remain unchanged and mark a team’s velocity will also allow us to better estimate how long features will take to be completed, as once over time we have reliable velocities in terms of estimated hours, it is easy to apply how many estimated hours we have queued up to have a firmer idea of what we can likely accomplish in a sprint, quarter or year even.
At the beginning of each sprint in sprint planning the teams can use a worksheet similar to the below to allocate story’s from the actionable backlog. The team will select the next most important stories whose estimated hours add up to approximately their velocity in estimated hours, allowing for individual team availability.
In their sprint planning sessions teams can then take the stories that they have decided to work on in the sprint and break them down into actionable tasks that can be assigned to specific developers. The teams can decide what tool to use to do this, they can make child stories or use a third party tool like Jira, YouTrack or Trello to manage at the task level. All time would be recorded to the main story if a team does not use child story’s to manage their task level work.
Team Meetings and Sprint Size:
In order to foster a sense of collaboration and developer buy in we are suggesting the teams have the following meetings every sprint:
- Sprint Planning Meeting
- Happens first day of each sprint. The team reviews the story’s assigned that sprint and breaks them down if necessary into smaller tasks they manage as child story’s or in Trello, Youtrack, or some other mechanism of the team’s choosing. Teams take in story’s from their actionable backlog to bring into the sprint. If a story is deemed not defined enough to be worked on it can be kicked back at this point.
- Goal of Meeting: To break down story’s into discreet parts that team members can work on. To include team members in planning process so their input is solicited prior to starting work.
- Duration: 4 – 8 Hours
- Attendees: The team and any stakeholder or manager that has an interest in providing input into how a particular story is implemented.
- Sprint Review Meeting
- Happens last day of each sprint. Team reviews how the sprint went. Team creates a list of things they did in the last sprint that they should stop doing, things they did in the last sprint they should continue doing, and things they should start doing that might help mitigate issues the team had in the sprint. Team members submit anonymous numbers between 1-10 grading how the sprint went. These numbers are used to gauge team morale. Finished features in the sprint are quickly demonstrated.
- Goal of Meeting: To gather feedback from team on how process is functioning. To gather ideas for how process and team can function better from people on the team and to create an environment of inclusion.
- Duration: Time boxed to 1 hour
- Attendees: The team and any manager or stakeholder who is interested in hearing about the sprint.
- Stand Up Meetings
- Happens every day. Each team member quickly reviews what items they worked on yesterday, what they are planning on working on today and what roadblocks they have. This is not a status meeting and should be limited to only items that are in the sprint.
- Goal of Meeting: To allow team to assess if it is on track an identify any sticking points as early as possible
- Duration: Time boxed to 10 Minute Maximum
- Attendees: The Team and any manager who is interested in hearing it.
In order to facilitate the number and duration of meetings sprints will be lengthened to three weeks so that there is enough development time to accomplish a meaningful feature load.
Teams should also sit together. Cubicles should be rearranged into team pods to foster communication and collaboration amongst team members.
Backlog Management:
Each team will have an actionable backlog where stories that are believed to be defined enough are placed and ordered by their priority. In each Team’s Sprint Planning meeting they pull in as many story’s from their Backlog as they believe they can accomplish, they should always pull in a number of story’s that is close to the estimated hours their velocity reflects they can handle. If a team needs to accommodate for support work that comes in unannounced then they should take in a smaller percentage of their estimated hour velocity to plan for the support story’s that are expected to appear during a sprint.
The team’s administrator should work closely with group management and stake holders to help make sure story’s placed in its backlog are actionable and can be worked on without too many questions needing to be answered.
To support this change Issue Manager should have a backlog field. This field will allow a story to be added into one of the team’s backlogs, and it is from these backlogs the team will pull when they do their sprint planning.
Management can plan work ahead by making sure story’ are well defined and adding them with appropriate priority into teams backlog.
Velocity Tracking
Only story’s that are entirely completed during a sprint are counted in the estimated hours that comprise that sprint’s velocity. All the estimated hours of a story that are finished in a sprint are counted in that sprint. Velocity is a rolling average so this will not impact the calculation of overall velocity and helps put the emphasis on completing a story entirely during a sprint.
New Developer Onboarding:
When new developers start, especially junior developers, the team structure should assist in their onboarding. Since new developers will be free of having specific story’s assigned to them (they are assigned to the team), they can pair with more senior members and work on tasks that add value to the team while they learn about environment and products. As they learn more and become more valuable they amount of effective hours expected can be increased during sprint planning. Teams can also create their own onboarding steps that are particular to the technologies the team most frequently works with. For instance, each team might have a set of pluralsight courses they expect a new hire to watch over the first 90 days of employment.
Build Changes:
To facilitate increased quality our Continuous Integration builds will be changed to break if a certain level of test coverage is not met. For new projects this can be a higher number than existing projects that have little or no existing testing.
Using dependency free unit testing the team should be able to implement code that achieves desired test coverage targets without creating brittle and slow builds that are based on databases existing and having correct data to support testing.
Functional testing will be separated into their own solutions and run on their own builds so they do no block development and the needed fast feedback from Continuous Integration builds.