How team works previously?
Before I joined, team was quite passive while facing to the new requests or scope change, every time when the unexpected requirements came, team has to stop the things on hand and start to develop and deliver the urgent one in a fixed time. Team member should always be ready for every temporary request. Also, product owner cannot have a reliable estimate on how long team needs to provide deliverables. The worse thing is, team member’s tasks were quite scattered, they don’t really know what others’ working on, therefore, duplicated or missing tasks occured sometimes.
From “Passive” to “Proactive”, we need Agile!
What is the value of Agile Project Management ?
- Team share only one goal in a fixed time, cultivate transparency and collaboration within team;
- All of the requirements are well-organized with different priority and dependency;
- Easy-to-understand metrics to evaluate teams speed and velocity in a fixed time.
As far as I’m concerned, once the agile project management is applied, the pain points that NetDev team is facing will be resolved gradually.
Deep Look At Agile Project Management
Traditional agile project management can be categorized into two frameworks: scrum and kanban. While scrum is focused on fixed-length project iterations, kanban is focused on continuous releases. Upon completion, the team immediately moves on to the next.
No matter what framework that is applied in my Agile project management, there are one goal they both share:
Rolling out an efficient progress for product development.
Therefore, I went through the properties of Scrum and Kanban before deciding which one I would apply to the current dev team.
- How Scrum works?
With scrum, your team promises to deliver some valuable increment of work by the end of each sprint. Scrum is built on empiricism, focusing on small increments of work that will help you learn from your customers and better inform what you do next. Here’s how it breaks down:
1.1 Scrum cadence
Scrum moves fast, with sprints of two to at most four weeks with clear start and finish dates. The short time frame forces complex tasks to be split into smaller stories, and helps your team learn quickly. A key question is this: Can your team ship useable code that fast?
Sprints are punctuated by the sprint planning, sprint review, and retrospective meetings and peppered with daily scrum(standup) meetings. These scrum ceremonies are lightweight and run on a continuous basis.
1.2 Release methodology
Nowadays, it’s common to have ad-hoc releases in scrum, but it’s long been a best practice to release at the end of each sprint. Teams set an objective for each sprint, the sprint goal, and either approves it for release in the sprint review meeting, or don’t.
1.3 Scrum roles
Scrum has three clearly defined roles.
- The product owner advocates for the customer, manages the product backlog, and helps prioritize the work done by the development team.
- The scrum master helps the team stay grounded in the scrum principles.
- The development team chooses the work to be done, delivers increments, and demonstrates collective accountability.
Who manages the scrum team? Well, nobody. Scrum teams are self-organizing and everyone is equal, despite having different responsibilities. The team is united by the goal of shipping value to customers.
1.4 Key metrics
Velocity — the number of story points completed in a sprint — is the central metric for scrum teams. It guides future sprint commitments, or how much work the scrum team takes on in future sprints. If the team completes an average of 35 story points per sprint (Velocity = 35), it won’t agree to a sprint backlog that contains 45 points.
1.5 Change philosophy
Teams strive to not make scope changes during a sprint. Scrum teams sometimes get feedback and learn that what they’re working on isn’t as valuable to the customer as they thought. In such cases, the scope of the sprint should change to reflect the importance of shipping value to the customer first and foremost. During the sprint retrospective, scrum teams should discuss how to limit change in future, as changes put the potentially shippable increment at risk.
2. How Kanban works?
Kanban helps visualize your work, limit work-in-progress(WIP) and quickly move work from “Doing” to “Done.”
Kanban is great for teams that have lots of incoming requests that vary in priority and size. Whereas scrum processes require high control over what is in scope, kanban let’s you go with the flow.
2.1 Kanban cadence
Kanban is based on a continuous workflow structure that keeps teams nimble and ready to adapt to changing priorities. Work items — represented by tickets — are organized on a kanban board where they flow from one stage of the workflow(column) to the next. Common workflow stages are To Do, In Progress, In Review, Blocked, and Done. But the best practice is to make custom columns for how your team work.
The configured board can help for learning how much the work your team can ship in a fixed time (say weeky, monthly, quarterly…) and where your bottlenecks are.
2.2 Release methodology
In kanban, updates are released whenever they are ready, without a regular schedule or predetermined due dates.
In theory, kanban does not prescribe a fixed time to deliver a task. If the task gets completed earlier (or later), it can be released as needed without having to wait for a release milestone like sprint review.
2.3 Kanban roles
The whole team owns the kanban board. Some teams enlist an agile coach but, unlike scrum, there is no single “kanban master” who keeps everything running smoothly. It’s the collective responsibility of the entire team to collaborate on and deliver the tasks on the board.
2.4 Key metrics
Lead time and cycle time are important metrics for kanban teams. The deal with the average amount of time that it takes for a task to move from start to finish. Improving cycle times indicates the success of kanban teams.
The Cumulative Flow Diagram (CFD) is another analytical tool used by kanban teams to understand the number of work items in each state. CFDs help identify specific bottlenecks that need to be resolved for better throughput.
Another way to deal with bottlenecks is through Work In Progress(WIP) limits. A WIP limit caps the number of cards that can be in any one column at one time. When you reach your WIP limit, a tool like Jira Software caps that column and the team swarms on those items to move them forward.
2.5 Change philosophy
A kanban workflow can change at any time. New work items can get added to the backlog and existing cards can get blocked or removed all together based on prioritization. Also, if the team capacity changes, WIP limit can be recalibrated and work items adjusted accordingly. It’s all about being flexible in kanban.
Decision
As we all know that regarding the tasks belong to the software development, a research can be involved (which the time cost is hard to estimate) and an implementation can be involved (which the time cost is predictable), therefore we can’t simply take Scrum or kanban as black or white, sometimes we may use a hybrid way to record and track the development with clearness and efficiency. Take the development of a SaaS product as an example, some features can be clear enough with UX design and deployment method, then the scrum can be implemented for estimated how much features can be delivered in a fixed-time. However, for some unpredictable items such as UAT or bugfix, it is hard for PM to predict all of the stuff in the spring planning so Kanban would be for suitable for these items.
In conclusion, we decided to completely implement Scrum in our team with 4 ceremonies: Sprint planning, Sprint review, Retrospective meeting, Stand-up meeting, with 3 roles: Scrum master, PO and dev team, while implement the Kanban sometimes, to make the whole process more flexible and stable with valuable deliverables.
Here is a typical burndown chart after we implement the Agile, ignoring the increase at the beginning of the Sprint caused by the uncompleted tasks automatically moved from the last sprint(we should try to avoid this in future), we got a relatively stable development during the sprint.
