Why continuous delivery is not enough?

Continuous Delivery has been treated as the best practice for almost a decade. I've seen a lot of teams who are doing it well. They have different types of tests to cover the business logic from UI to a database.  They follow the test pyramid quite well to have minimal effort with the maximal coverage. They are able to do a release with only one click if their product owners ask for.
However, when a system-wide refactor (such as changing to a better json library or a big version upgrade to a dependency) needs to be done, they show caution instead of confidence. Why is that? Shouldn't they do the change, push to CI, then deploy to production if it's green? If your team can have the confidence to do this, congratulations, you can remove the button before the production deployment and go one step ahead: Continuous Deployment.

There are more reasons to do Continuous Deployment as well:

• Real automation & 100% coverage - there would be no manual test allowed in any cases after pushing a commit. This force teams to automated really everything including visual testing for long term benefits.
• Better quality assurance - quality doesn't require any manual tests, there would be no human mistakes
• Easier to return tech debts - Fully test coverage help teams do any change without considering testing effort. This can reduce the cost of a system-wide refactor to less than a half. And more importantly, it changes the way to do a big refactor from a team delivering activity to a purely developing activity.
• Less waste - teams have no chance to implement anything without deploying to production. This would force the team and PO to work more closely to take the responsibility of releases together because the PO and the team need to find out the client impact/value of any change before the team push the commits. However, continuous delivery still opens the chance to the PO to change his/her mind in the last minute. 
• Get feedback before the implementation vs after the implementation - we have enough technologies to handle both situations well. We can easily create mock-ups with business flows to get early feedbacks of a design with very low cost. We can also have feature toggles to enable the later feedbacks from the PO and a small group of users with much higher cost. In fact, if the PO and the team work closely and have those early feedbacks, the team can remove one type of feature toggles (which is the switches of functionalities) and most other feature toggles will not be needed, so the value/cost ratio is increased.

So, are you ready to remove the one-click button? Do the following practices:

1. 100% business coverage - make sure you follow TDD all the time, even the css changes should also be covered by visual tests. And don't forget to automate all the non-functional requirements as well.
2. Zero downtime deployment - Most teams who achieved Continuous Delivery have already implemented this. If you haven't, do it because you will deploy many times each day and your users shouldn't feel that.
3. Monitoring & Alerting - do live check and health check for not just the service, also the dependencies to make sure you are notified if anything goes wrong

These practices give you the confidence to say a green CI build means that the application deployed to production with high quality and no customer impact, otherwise, you should get alert from your on-call system immediately.

In summary, Continuous Delivery is good but not enough to be excellent, you can improve your team's productivity by going forward to Continuous Deployment.

Agile Team Evolution Theory (3 stages toward high responsiveness and fast delivery) - Part I

Why I’m writing this?

If you asked a question "What is Agile Development?” to other people, most of them would give you different answers. And the more you ask, the more confused you get, doesn’t it? When you moved from a company or a team to another, did you feel the difference in doing Agile practices? And why is that?
How you understand Agile Development depends on what Agile practices you have experienced, and what Agile practices you experienced depend on the team you have joined. What practices your team choose are the results of a series of decisions, and the decisions the team made depend on what they care about which is called context. In different Agile teams, the context is different so that the priority of problems or goals are different.
However, there are 3 high-level goals that any team wants to achieve for their product in whatever context, which are quality, responsiveness, velocity. Waterfall Development has done a lot of improvement on quality and velocity but nothing to do with responsiveness. That becomes a huge problem for living in a changeable market which requires value-oriented delivery. That also becomes the original motivation for most organizations to adopt Agile Transformation. But in most cases, while the responsiveness is increasing, the quality and velocity are decreasing. On the other hand, an Agile team is able to deliver value with quality to production in hours with low cost, which means all the goals are achievable. So the question becomes how? If we break down the high-level goals and mixed with the context, we can see a journey from Waterfall Development which is normally in a hierarchical organization with heavy department walls and deliver features in years, to Agile Development which is normally in a flat organization with autonomy environment and deliver features in hours.
I’m very lucky to have the opportunities working with more than 20 teams on the different stages of the journey. Some were just starting, some were in the middle, some were very agile. And because my goal was to help them moving forward, I tried a lot of practices among all these teams. I got a lot of feedback from those experiments. One thing came out, the same practice was working on one team might not be working on another. In the beginning, I thought that is what we call “it depends”, isn’t it? But afterwards, I couldn’t stop thinking. Why it depends? What does it depend on? People? Yes, because everything is done by people. But also no, because people are subjective, is there anything objective to let it happen? I kept finding. I tried the same practices in more teams, and finally, I found some patterns. And these patterns are very good to describe the Agile journey.

In this series of articles, I'll describe the journey as 3 stages. Each stage would have only one goal with different approaches for different scenarios. I'll also explain why the goals have to be achieved in this order and why some practices only benefit teams in one stage but not in another. Before jumping into the first stage, let's talk about why the starting point of the Agile transformation is Waterfall Development.

What is Agile Development?

The definition from Wikipedia is "Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).” However, if you ask the question to people, you will get a lot of different answers. A lot of people say Agile is about delivering value to the customer instead of delivering functionalities which might not have value. That’s right, we serve the customer to solve their problems so we can earn the money from them. A lot of people may also say Agile is about delivering software with better quality. That’s also true. We want to deliver qualified software at any time. And there are also some arguments between responsiveness and speed of delivery. Of course, the best to have both of them.
But why we have so many right answers? To understand Agile Development better, we need to look back to the history.

The history of Agile Development

The first time we have the word “Agile" is in 2001, the well-known Manifesto for Agile Software Development was published in Snowbird by 17 developers. And the popular Agile frameworks are also published around that time such as XP and Scrum in the 1990s. At that time, a lot of organizations were building big ideas into big software and systems with Waterfall Development. Since the popularization of the internet, the market gets increase rapidly, more and more small software products succeeded along with more and more big projects failed, even before the first release. Because of that, more and more people started to seek a way to deliver software with more possibility of success which requires delivering software with quality in a small period of time so the company has more chance to get customers early. And Agile Development was born for this purpose, reducing the lead time of feature delivery and not damaging the quality at a reasonable speed. The shorter the feature gets to the customer, the faster feedback comes back, the better understanding the company have of the market, the more chance they could succeed. So from that point, people start to give up Waterfall Development and transfer to Agile Development.

Stage 0 - Waterfall Development

In Waterfall Development, the delivery of software is split into multiple stages. In high level, they are planning, design, developing, testing, and release. Each stage is taken normally months and done by different people from different departments. Long documents are usually used to pass the information among them. To make sure the quality of each stage, teams need to sign off the documents from the previous stage. This process looks perfect if all the teams can finish their job perfectly. However, this is hard and a lot of companies failed or changed. But some companies in some traditional industries such as banks are still alive and working in this way.

Why they still alive and what they did to improve their process?

• First, they all have a strong business to support them, obviously. 
• Second, inside the organization, they have very strong process management and standards which define what everyone should do in which stage.
• Third, very limited technical stacks (normally very old as well) to make sure all the technical persons having the same required knowledge.

If you think about building a building, the building designer needs to give very detailed information, such as where needs how many rebars in which type. This requires the designer to understand the materials used by the building and the workers also need the same knowledge. Even the quality checking person needs to have the same knowledge. In software development, hiring teams having the same knowledge is not possible for most companies. But it’s possible if you have enough money to define all the standards with limited tools and technologies (normally are expensive and commercial) in design, coding, testing, deployment, and collaboration. You can give professional training to all the new employees to make sure they all have the necessary knowledge.

So see? Waterfall development seams working well except the release cycle is too long and all features releasing together. And this leads to some problems:

1. Very hard to put hotfixes into production - hotfixes are not possible to wait until next release cycle, and it’s also not possible to deploy the new codes of hotfixes immediately from the current codebase because the codes of new features are already there. One way to solve it is to have a clean release brand, put all the hotfixes into that branch and go throw the release process to push it into production. In most cases it's fine, but sometimes, it’s still too slow. So some companies allow the developer to change the production code directly with the approval of their manager in some very urgent cases. And I don’t think anyone like it because of the risk the action brings. Also, there is another problem which is the double effort. Whatever you have done on the release branch, it needs to be merged into the developing branch and go throw all the test cases, which have been done in the release branch. Another solution I’ve seen is that they write all the code in the developing branch, then use something like cherry-pick to pick the change to testing branch and release branch. However, this is a high-cost solution which requires someone to review each pick and never works well because of the complexity of the job itself. Also, I’ve seen a company allows the developers to use their local machine to make the package and ask the release team to deploy it (the package still needs to be signed off by the manager and the testing team) which is similar to a release branch.
2. A lot of low-value functionalities were delivered into production - because of the long release cycle. If the business failed to push their idea into production at this release, they have to wait for another very long period. Because the business is not getting feedback from the customers, they can only judge the value by their experience which we know it’s normally wrong in a rapidly changing market. So instead of putting the partial idea into the market to have a test, they prefer to push the whole idea at once. And unfortunately, many parts of the software are never used.

To avoid these problems, we have to make the release cycle much shorter. We can either to make the release cycle in a fixed short period or to release feature once it finished. This is the first step to enable value-oriented delivery. We will talk about how to do it in Stage 1.

Someone maybe wants to ask, why not starts the transformation from improving quality or reducing cost?

• Quality - in the Waterfall process, the responsibility of quality belongs to the testing team. They do a lot of different types of testing on the software multiple times. So normally the quality of software is quite good after all these tests. And even if it was not that good, the company would put the effort into the testing department, not the development department, which would make the flow longer. It’s just an exchange from velocity and responsiveness to the quality. So that's not what we want.
• Cost -  Many people feel Waterfall Development is expensive. But it is not always true especially when all the resources are well organized. Testers are cheap, devs with just enough coding skills are cheaper than devs with TDD and clean code skills, Architects are shared among teams, release teams are also shared. Plus there are processes to control the budget and manage risks, the cost is normally reasonable. And even if the company wants to reduce the cost, it would try to cut down projects, resources instead of improving the efficiency, which is also not we want.

Reducing the release cycle helps to improve responsiveness but not velocity. Velocity means the values delivered in a period of time with resources (value/cost). Increasing velocity means either to deliver more value with the same cost or the same value with less cost. As I mentioned above, we need a shorter feedback loop to achieve higher value with the same amount of requirement. So before we have better responsiveness, velocity is only able to represent as speed which is functionalities/cost. If the capability of a team was not changed, increasing the workload would lead to impact other hiding factors such as quality and tech debts. And the increasing of tech debts or the decreasing of quality leads to more unplanned time and finally slows down the speed of delivery. So before the team seeks the fast speed, they need to have the responsiveness and be able to deliver qualified software first.

Stage 1 - Start

Goal: Release faster
Key Indicator: Lead Time - From Yeas to Weeks

There are quite a lot of Agile frameworks. The most popular frameworks are Scrum and Kanban. Scrum is to make the delivery period fixed so that force the team to deliver a small batch of requirement. Kanban is to ask the team to focus on one thing at one time so that they can release each feature as early as possible. But because of the complexity of software development, both of them needs to involve a lot of practices. Where should you start?

Planning

A lot of people think the planning is not necessary for Agile Development. The deadline for a requirement is not needed. The team just needs to focus on delivery. They don’t need to tell the business when the job might be finished. And the business needs endless passions and confidence in the delivery team just because they call themselves Agile team. That’s obviously not true.

Why we need to plan before delivery?

Planning is always the first step in doing anything. Everyone is planning all the time. For example, before we have dinner, we always plan what we gonna eat. To make a better plan, we need to have more information such as looking for a restaurant or searching for food from a fridge. You may not plan until the last minute like when you felt hungry or someone invited you. However, in software delivery, those kinds of last-minute plan don’t work. We need to know what the team is going to delivery and when the team can delivery because the company relies on this to plan the limited budget and the business relies on this to plan the events of client interaction. Without a proper plan, the company might encounter a cash flow fracture without warning, the business might lose the change to get customers.

Why planning is hard in Waterfall Development?

Because the planning is so important, we make plans all the time since the first day we develop software. However, in Waterfall Development, most of the plans don’t work. Delaying plan, adding more budget, hiring more developers are so common in software development. And we have the reason that software development is not predictable. So many small unplanned things come out during the development, such as the misunderstanding of the requirement, lack of knowledge of the domain, waiting for a dependency, a bug from a library, learning about technology, etc. Because the development team can’t solve all these problems before planning, they have to leave buffers for uncertainty in the development phase. However, the business and the manager know that and they want to get a plan without buffers. So the communication between the development team and the business will be a negotiation. And in a negotiation, two sides, of course, have different goals. So as we know, the result will be a plan no one satisfied.

How we can make a plan better?

Be clear, it is not possible to get rid of all the problems before planning, a common way is to have an inception stage to remove those problems so that we can have a better plan. However, the number of problems is in direct proportion to the size of the requirement. And in waterfall development, the size normally is huge so the number of problems is also huge. Another thing from software development is complexity. In a large system, codes interact with other codes, functions interact with other functions. It’s not possible to fit all the information into our brain. That’s why a wrong decision normally is found in a very late stage. Design decisions affect each other and it’s hard to realize wrong decisions until we start to write the code. There are tools, principles to reduce those wrong decisions, but there is no silver bullet, so none of them can reduce problems to a reasonable amount.
Sine the number of problems is related to the size of requirement, so the better way to make a plan is to reduce the size of requirement, which leads to deliver less but multiple times. The smaller size of requirement we plan at once, the more amount of problems reduces, the more accurate plan we can get.

The inception

We keep the inception phase but make it shorter (normally from 2 days for a 1 month project to 2 weeks for a 6 months project), change the goal from making a fixed delivery plan for everything to a changeable high-level plan for the project with the detailed delivery plan only for next 1 or 2 iterations. In this case, a professional team are normally able to solve most of the problems during the inception and get ready to start delivery.

Risk management

Like the normal project management, the plan must have a resources plan and a goal with a roadmap which includes the estimated time of each milestone so that we can define risks and make decisions like adding more resources or reducing the scope when there is a risk.
Sometimes, there are uncertain problems which are not possible to make an estimation. In this case, you can say you don’t know when and how to do it, but you have to have a plan to find it out. It can be a spike with a fixed time frame or find help from someone else.

Summary

In Waterfall, because everything is going to release together, so normally everything is mandatory. There is no clear priority among requirements. But now because we want to give a better plan only for the near future, we need to decide what we deliver first. Which means we need a clear prioritized requirement list to help us deliver multiple small versions in desired order instead of a big version. The smaller pieces of requirements, the easier we can prioritize them and deliver them. So how can we make a requirement small as well as deliverable? In agile development, we write the requirement into a Story.

Story based requirement management

In the Waterfall process, business used to put all the requirement of a feature into one document. For example, if they want a bank mobile app, a big feature of account management will be in one document, login will be in another document, money transfers will be in another and so on. The business put all the details into those documents without splitting and prioritization because they will be delivered together. So when a development team starts to ask the business what should deliver first, the answer from business is normally a big feature such as login or account management. However, if we deliver login only to users, there is no value to them. Who wants to use an app which is only able to login? And if you get closer to the business, you will find that some part of a feature is more important than another part. So why we don’t deliver parts of multiple features such as login without signup, displaying existing account information without editing and adding, transferring money only between user’s accounts in the first version, then continuously adding other parts of features in the following versions? That’s what we do in Agile development, to deliver small pieces of value in short periods frequently. So far, we have found out 4 most important elements of a story, the user (Who), the reason the user wants (Why), the behaviour the user wants (What), and the scope (Which part).
In the Waterfall process, the documents of requirements are used by development teams to write code and by testing teams to write test cases. They understand the same documents from different perspectives. And because testing is the next step of development, a lot of misunderstandings, especially for different scenarios and corner cases,  are found in the later stage. To reduce the number of misunderstandings, the developers and the testers need to get agreement on how to check the story is done. So we write down acceptance criteria (AC) on stories.
Also, we noticed the story is just a part of a feature so that it might not be able to be delivered until some other stories were delivered. Or in a complex system, a development team might rely on another team to provide an API or a component. We list these dependencies on a story so that the business and the development team know it can't be planed until all dependencies have been removed. Of course, in an ideal world, we shouldn’t depend on other teams, we should have access to the whole codebase and be able to change all of them on our own. However, that’s not possible in a team who just starts Agile Development.

Elements on a story

• User - Tells the team who gets the value. In most cases, it is the end user. In some cases, it can be the business. For example, the payment function. It's the business who wants users to pay, but the users normally want everything for free. So the story can be written in "as a service provider, I want to add a 1% surcharge on each cross-bank transfer so that I can sustain my business”. And for users, they want to see the surcharge so that they can make the decision whether they use the service or not. In rare cases, it can be the development team. Such as setting up a pipeline or build automated deployment. Some people also call them tasks instead of stories. Whatever they called, all of them should help the team to deliver faster.
• Reason - Tells the team why the users need the functionality from the business perspective. This represents the value of the story. This plus the user are the most important part of a story. First, if a function has no value for anyone, then why we put money on it? Second, by clarifying the goal, it gives the team a chance to find a better solution.
• Behaviour - Tell the team what the users want. This part is negotiable if the delivery team can give a better solution to achieve the same value. In the Waterfall process, normally the lead developers and the architects are responsible to tell the business the duplicated part of requirements or to remove the duplication and simplify the solution by technical design. But in Agile Development, the delivery team talks to the business directly, so they need to find the duplication and the chance of a better design on their own.
• Scope - A clear boundary of a story. Stories are normally split from a bigger story which is called feature or epic. It’s very hard to distinguish them by only descriptions. Clarifying boundaries among stories and telling what will be done in other stories help the delivery team focus on the current story and avoid to deliver something unnecessary.
• Acceptance Criteria(AC) - The common understanding among everyone about how to check whether the story is done from the business perspective. There should not be any check related to implementation, such as saved in a database or a method has been called. There are other conditions of done, such as deployed into production or passing all the regression tests which we will talk about them later.
• Dependencies - A checklist for starting a story. Make sure remove all the dependencies before picking it up.

Common format of a story

<Card Number> <Title>
As a <user>, I want to <do something>, so that I can <get some value>.

Acceptance Criteria:
1. ...
2. ...

Dependencies
1. This has to be done after <Another Card Number>
2. Rely on <other team> to <do something>
3. ...

Out of scope
1. <some functionalities> will be done by <Another Card Number>

How to check a story

In Agile Development, we normally use the acronym “INVEST” to check the quality of a story.

• Independent - a good story is able to be delivered independently
• Negotiable - everything is changeable on a story if you have a better replacement
• Valuable - be clear about why to deliver the story
• Estimable - small and clear enough to give an approximation to other stories
• Small - small enough to fit into an iteration and deliver it quickly
• Testable - a story is able to be tested based on the output. Which means the person who is testing the story should not care about any implementation.

Beyond INVEST, the priority of stories is also very important. The business needs to be clear to the delivery team what they want first.

Example of a story

BMA-010 Transfer between my accounts
As a bank client,
I want to transfer my money between my own accounts,
so that I can put my spare money into my saving account to get more interests.

Acceptance Criteria:
1. The user has more than 1 accounts, the user is allowed to transfer money under the balance between the accounts
2. There is no limitation of the amount as long as the user has enough balance in the source account.
3. The user is not allowed to transfer money if there is not enough balance.
4. The user is not allowed to transfer money in minus or 0

Dependencies
1. This has to be done after #BMA-001 Login and #BMA-002 list the accounts
2. Rely on back-end team to provide the transfer API

Out of scope
1. Money transfer to others will be done by #BMA-011

Comments: BMA = Bank Mobile App

Story wall

In Waterfall Development, each feature in a document is assigned to a developer with a planned start date and end date. The developer updates the percentage every day to track the progress. The manager tracks the progress of all the features to make sure the project is under control. If any progress is slower than expected, the manager will go to the person and ask why. There are two results of this risk management model.

1. The developers report the real progress and get asked every day. They push all the reasons of delay to other people, such as waiting for dependencies, requirement changes (actually it’s misunderstanding in most cases), bugs introduced by others in the related components, but no one talks about the original plan (because it was made by their manager), the code quality (because they wrote the code), the inefficient tools the company provided (because all the tools come from the higher managers and cost a lot), the time they spent on fixing defects (because they created those defects). Then the manager collects all the problems and solves these problems by communicating with other managers. In a Waterfall project, a manager can have 5 - 10 developers, if each developer reports 3 problems every day, the manager needs to track and solve 15 to 30 problems every day. So solving problems would become the most time-consuming job for them every day, but no essential problem would have been solved. Finally, the project delayed with all these “unexpected” problems and everyone gets rewarded because of the hard work.
2. The developers report the fake progress. So they don’t get interrupted every day by their manager. But the developers need to make the fake progress not that fake, so they start each feature on time and build the minimum version of each feature and ignore most corner cases. So once the development team submits the application to the testing team, a huge amount of defects would be found. The testing phase would be much longer than expected so that the project has to be delayed.

So none of them gets a good result. We need some better way to track the progress. We have talked about how can we make the plan closer to the reality in Agile Development. The smaller plan with stories. Now I'm going to introduce how the Story Wall can be an effective way to track the state of the plan with visualization.

1. The real progress - real progress helps us to find the risk ahead and adjust the original plan accordingly. So how can we have real progress? 
1. Checking the facts instead of reporting - in Waterfall Development, the progress relied on the reports from each developer. In Agile Development, the progress relied on the objective facts. Since we can’t deliver a story without finishing it, the easy way to define the progress is “stories in done” / “stories planned”. For example, you plan to finish 5 stories in 2 weeks, after the first week, you check your progress to be 40% as you finished 2 stories and 1 story in progress. In the old way, it might be 50% which means no risk. But now, you see a small risk based on the number, so you plan to check more frequently in the second week and take actions if it’s necessary. You might realize that there is a gap between the defined progress and real progress. We can reduce the gap by reducing the size of the stories. And we can ignore the effect of the gap once the size of stories is small enough.
2. Define what is done of a story - the team needs an agreement on what’s the criteria for delivering a story. At the beginning of the journey, it is not necessary to be in production since some organizations have a very heavy release process which is not possible to be replaced or automated immediately. But the story is at least tested in an integration test environment and ready to deploy to further environments.
3. Define the value stream of a story - if you only want to check the progress, columns backlog -> in progress -> done is enough. This is how Scrum board looks like. However, it’s not enough if you want to find any opportunities to improve the responsiveness. We will talk about it later.
4. Update the state of stories in time - the ideal situation is to update the Story Wall immediately if any state of stories changed. However, not all the team members do that which I guess because of the cost of the action. So sometimes, having a physical wall or a big touchable electrical wall nearby is helpful.
2. Identifying hiding problems - problems are also opportunities for improvement. Instead of pushing all the problems outside, being open to the problems inside as well.
1. Have a clearer view of stories - to be able to find the hiding problems, we need to understand what obstacles to stop a story moving on. And that requires more information, who is working on it for what. So we need to expand “in progress” column into more stages. Here I've listed some high-level stages to production, you can choose a part of them based on your definition of done.
1. Backlog - a column for the team to get a brief idea of a project
2. Analysis - a column for BA or UX when a story needs more information to be started for development
3. Ready for Dev - a column for BA to store the stories in priority, which have enough information and are ready to be picked up
4. Developing - a column for Dev. Pick a story from Ready for Dev when a Dev is free and put the Dev's name on it.
5. Dev Done - a column for Dev to store the stories which have finished in coding and ready for test
6. Testing - a column is for a QA/Tester. Pick a dev-done story into this column when a QA or Tester is free and put the name on it
7. Ready for Showcase - a column for the team to store the stories which are well tested. Stories in this column are ready to do the demo to the business or the users.
8. Ready for release - a column for the team to store the stories which have been approved by the business and ready to deploy to production. Notice that this column would not be useful once you got the capability of continuous deployment in stage 2.
9. In Production (Done) - a column for the team to see what stories are in production
2. Anti-patterns of a Story Wall - these patterns help the team to find problems and seek opportunities to improve
1. Cards bouncing between columns - this normally happens between Developing and Testing because of the quality of development. This is an opportunity to shift the responsibility of quality from QA/testers to developers.
2. Multiple tasks - if you see the same name on more than one story, the person must be holding to more than one stories. There are a lot of reasons. It could be an urgent story/defect coming across,  the developer stops the current work and pick up the urgent one, which means the previous story is not in progress. In this case, the padding story is better to be pushed back and get chance to others to pick. Another reason could be that a story in progress is blocked by some obstacles which are not possible to remove shortly so the developer or QA picks another story. In this case, they could put a warning post on the story and check it regularly.
3. Unassigned Story in Analysis, Developing or Testing columns - this might happen when a person takes leaves. In this case, it's better to push the story back and wait for others to pick it up
4. Has not moved for a long time - it’s very easy to find out a story in one column for days if you use the Story Wall. Find out why and try to avoid this situation to happen again.
5. Too many stories in Ready for Dev or Dev done - this is a change to find the bottleneck of the team. It’s the opportunity to try cross-role team which means anyone can be any role when the team needs.
3. Visualization - we all want to make our team better. And to do that, the team needs to get a better understanding of themselves first. A Story Wall nearby helps that by allowing them to see the state of themselves anytime they want.

Collaboration based on stories

Requirement document helps the communication between different teams be efficient by setting up the context in Waterfall Development. Any updates of a feature would be recorded into the document and spread to all the related people. The same thing needs to happen on stories.
We can easily use stories to replace the documents to set up the context to make the conversations more efficiently. Any outcome or the important information can also be attached to a story to avoid the same conversation happened again. We can record them as comments of a story if you have an electrical wall, or record them on a post and stick it on the story if you only have a physical wall. With a Story Wall, the information will be spread automatically. And in case someone isn’t noticed, the information can also be mentioned in a Standup (a common practice in Agile Development, I’ll explain later).

The lifecycle of a story

Once a story is delivered, the information on it has been translated into the code. If we kept updating a story while writing other code, we would have the duplicated information with double cost. To avoid this, discard a story when it is done and create new stories for new requirement based on the working software, which is different from the Waterfall Development, updating the existing document for new changes which are based on the document.
So the lifecycle of a story starts from the backlog, goes through each stage of the value stream, ends at done.

Summary

Using stories instead of documents to manage the requirements increases the efficiency of collaboration between different roles. It gets easier to be priorities, easier to be planned, easier to be tracked. It changes the way of describing the requirement from function-oriented to value-oriented. It’s a core stone of Agile Development, which defines what should be delivered.

Delivery

As mentioned above, we need to deliver in small batches with short periods. But it is not possible if we keep all the process of Waterfall Development. Think about how could it be possible to finish a story quickly if it needs a design document before coding and test cases before testing, if all the documents need to be reviewed by leaders, if each move of a story needs to be submitted in a system and signed off by a leader from another department which might take days. It is not so we need a light process instead. However, not all the organizations are able to apply the lightest process at the beginning. So based on the situation of an organization, there are 3 chooses for a good start point.

1. Build a new feature team and apply Scrum if you are in an open environment which allows you to make mistakes and do some experiments, and the product you are building doesn’t have complicated dependencies which require a lot of integration testing.
2. Optimize your team to remove the wall between departments and apply Kanban if you are in an open environment but your product has complicated dependencies such as hardware involved development or the different skill set required development.
3. Add QA/testers into your development team and apply Small Waterfall if your organization is very conservative which doesn’t like a lot of changes at once.

Scrum

Scrum is a well-defined framework of Agile Development. It has one delivery team with a PO and a Scrum Master to deliver in the fixed periods which are called sprints and each sprint has 4 types of meetings (Planning, Standup, Review, Retrospective) with a business showcase.

Practices

• Sprint - it is a fixed time frame which means it is not allowed to be delayed. It forces the team to adjust the scope instead of the time.
• Showcase - demo to the PO what value has been delivered for each sprint, which helps the team to get faster feedback from the business and build trust between the business and the delivery team to enable collaboration instead of negotiation.
• Planning - product backlog is made in product planning which is normally done before the first sprint. Sprint planning happens at the beginning of each sprint which creates a sprint backlog and defines a sprint goal.
• Standup - is also called as daily scrum. It happens every day to synchronize the progress and obstacles so that the team is able to find the risk as early as possible. A Scrum Master needs to make sure the team doesn’t treat it as a report meeting, instead to spread the responsibility of success to the whole team instead of the project manager in the old way. Each team member is responsible to find the risk and help others.
• Review - it happens at the end of a sprint to check the key indicators and how they have done in the sprint. All the information should be open to the team includes the result, the way to calculate, and the way to collect data.
• Retrospective - look back to the sprint and find anything they did well or could be improved, take actions or experiments in the next sprint. Again, the Scrum Master should make sure that everyone in the team has the responsibility to improve the team, not just the manager which is like the old way.
• Feature team - a team is able to do all the necessary things to push to production. Dev role to write the code, QA/Tester role to test the software, BA role to get all the business information the team needs, Ops role to deploy to all environments. Roles are more about the capability, so it is not necessary to be one role one person, such as a Dev can also be a part-time Ops.

Definition of Done of a story

• Based on the situation of the organization and make it as close to production as possible.

Key Indicator
From a fixed scope to a fixed period, the habit needs to be changed. In fixed scope, each feature used to get planned in a start date and an end date. The team track both dates because they believe if a feature gets started on time, it has a higher possibility to be finished on time, which is not true because of the cost of multiple tasks. And the real problem is that the plan has too much requirement which is more than the capability of the team. To avoid the delay of delivery, the team needs to make the plan match the capability. That’s why we need to track Finish Rate of each sprint.

• Finish Rate - the number of stories finished/the number of stories planned. Fixed period means 100% finish rate

Kanban

Sometimes, the software delivery team needs to integrate with a hardware team or other delivery team which has totally different technical stacks, and the integration part takes a lot of time so the lead time of a feature will be very long and not estimable. In this case, we can adopt framework Kanban which is based on Lean Thinking. The basic idea is to reduce the lead time by finding out and visualizing the current value stream then adding a limitation of WIP to each stage to let the team focus on delivering one value instead of many values together.

Practices

• Value stream - find out the current value stream which from the backlog to production includes all the integration stages across all the teams and departments.
• Visualization - use the value stream to make a Story Wall
• Pulling System - add a limitation of WIP to each stage. Allow a story to move to the next stage only when it is not full. If it is full, the person needs to try to help to move the stories in the next stage forward first. If this happens a lot, then you need to think that there might be a bottleneck and find a way to increase the capability for the next stage. 
• Limited WIP - continuously reduce the limitation of WIP for each stage to find more waste in the delivery and give the team changes to improve
• One Piece Flow - one feature at a time, which means not picking another feature until the feature has successfully handed over to the next stage. There shouldn’t be a lot of waiting time to move values forward, which requires that recourses for each stage are well balanced and the handing over are smooth.

Definition of Done of a story

• Deployed into production

Key Indicator

• WIP - The lower WIP is, the smaller batch is. So how low the WIP is, how successful the team is.

Small Waterfall

To apply the frameworks above from Waterfall Development, both of them need to change to organization structure in either way of merging departments and splitting into feature teams to serve the existing products or creating a new department with maybe a new product to do the experiment. However, in some organizations, they are not able to do these kinds of change. So is it possible to do the transformation in even smaller steps? The answer is yes but with some conditions:

• Accept longer time of transformation, it can be several years. I have seen some companies were still in Small Waterfall after 2 years doing the transformation and it might take even longer to move to the next stage.
• Accept much higher cost during the transformation. Because of the department wall, the collaboration is based on the responsibilities and rules instead of trust, so there is a lot of time to be spent on making the new collaborating process and rules and a lot of waste on the duplicated work in the different departments. For example, when the development team started to take the responsibility of quality, they would do a lot of tests which would also be done in the testing team.
• More people for all the departments. Because the Waterfall process has remained, to reduce the release period, all the departments need to do more work than before such as regression tests, deployment. They also need to learn a lot of new knowledge such as the new way to plan, the new way to write code, the new way to test, etc. All these work needs more people especially in the beginning of the transformation before they become automatic.

To apply Small Waterfall, we need to keep all the existing process from the requirement handing over to sign off of testing and deployment. The first change is to change the planning from a big batch to a small batch as mentioned above. We fit stories into fixed time frames. Running the time frames of design, development, testing parallelly. We also need to deal with the dependencies because of the different priority of different teams.

• Dependencies - in a big batch, the delivering order of requirement is not that important because they will be released after a very long time and all together. But in a small batch, the outside dependencies become a very big problem. For example, your business owner wanted your team to deliver a feature in the next iteration. But you found that it needs API support from other teams after you finished the design. You submitted a requirement to that team and they told you it needs at least 2 iterations to finish (assume that they had treated it as a high priority already which does not normally happen). Then you had to tell your business about the situation and change your plan. Because of this, a lot of high priority features are not able to deliver as expected. To solve this problem, we need to find out those dependencies early such as in the product planning. We need senior developers and architect to be involved in the early planning stage. Identify the dependencies as many as they can by doing a brief design which requires the knowledge of both the system and business. They need to know what data the team owns and where to get the data they don’t have. After you make a list of stories for those dependencies, you invite those teams with their business owners to make a big plan together. The big planning meeting can be a regular meeting which can happen every 3-6 months. During the meeting, all the teams need to get agreements on the deadline of the requirements and plan their stories before the deadline. It also needs an owner to update the delivering state of those stories which helps to identify the risk as early as possible.

The next change is in the development team.

• To reduce the unpredictability of the testing and following steps, the development team needs to include a testing phase for each story to increase the quality of the outcome of development, which normally we call it “dev test”. It needs to be done by someone else such as a full-time tester or another developer. However, testing by another developer is normally not ideal because all the developers have their own mission and they wouldn’t treat the test as a high priority. So the testing might not be sufficient because it would happen at the end of an iteration. The better solution is to have more than one full-time testers to test each story after the coding finished so the developers could get faster feedback and the stories would have enough tests. There is some waiting time for devs and testers at the beginning and the end of an iteration. But this is the additional cost we have to pay, otherwise, we would have more waiting time after development stage, more unpredictable unplanned time for all the teams, more possibilities for the delay of releases which might affect several products. Remember, the fixed release cycle is the goal for this stage. 
• The dev test requires a dev environment to run the software. Because it’s in the developing stage, not all the dependencies are available, so they need to use stub servers to simulate the behaviours of those unavailable dependencies.
• The dev test needs to be done during the iteration since it’s part of the development stage. The planning needs to include the time of dev test for each story.

At the same time, the deployment team needs to start learning automation.

• Build a deployment pipeline for the development team to allow them to deploy the code into dev environment by themselves, which helps them to do dev test easily.
• Build other pipelines for themselves to deploy the code to other environments easily so that they can handle the release more frequently.
• Automate the database changes by using the database version control.

Practices

• Iterations - it is a fixed time frame which means it is not allowed to be delayed. It forces the team to adjust the scope instead of the time. The testing iteration follows the development iteration. All the related deployment teams should have the same time frame.
• Collaboration - understand the impact of your job brings. Help other people finish their work more easily by finishing your job in high quality. Beware of the unreadable codes could slow down other’s coding speed, the defects could increase the risk of delivery, the delay of a dependent story could delay a group of features delivered by other teams. To avoid affecting others to get the job done on time, everyone needs to keep communicating and updating the state to the related person for the related job, and solving the risk as early as possible.
• Cross-Team Planning - teams working on different components need to plan together regularly to align the deadline of the dependent stories. Then reduce the number of dependent stories by expanding the ability of teams, refactoring existing components, and building new products with better design.
• Dev Test - induce a testing step in the development stage for each story. The stories are not allowed to submit to the next stage without passing the dev test.
• Auto Deployment - the ops team needs to make deployments automatically so that they can support the increase of deployments.
• Resources Support - make sure each team gets enough support in training, learning, and people. Reduce the scope instead of pushing the deadline to the team. Accept the real capability and help the team increase it continuously.
• Release Train - the fixed date to release a group of products and components so that all the dependent stories can be deployed together. The length of time between two releases should be the same as the iteration so that the stories of each iteration can be released to production.

Definition of Done of a story

• For design teams, done means dependencies found, data designed, mockup provided, INVEST matched
• For development teams, done means the dev test finished
• For testing teams, done means passing all the test cases
• For other related teams, their work isn’t tracked in a story level, so no meaning for them

However, the development team still needs to track which story is in which environment by putting stories into versions and track versions as waterfall process.


Key Indicator
Just like Scrum, use finish rate to make sure the plan matches the real capabilities of teams so that teams can achieve delivering small batches instead of a big batch.

• Finish Rate - the number of stories finished/the number of stories planned. Fixed period means 100% finish rate

Since the different stages include different teams, we can track the finish rate separately for each team.

Defects

Defects are found in 2 ways, before delivery and after delivery. As the team just started in the new delivery process, they can keep the way they have for the defects found after delivery. For the defects found before the delivery, which means at least one of the AC of a story hasn’t fulfilled, developers could pull the story back and finish it as soon as possible.
If a “defect” is not related to any AC of stories, it’s either a missing story or a missing scenario of a story. In this case, if you can deliver without the new scenario, create a new story into backlog and plan it for later sprints/iterations. If you have to deliver it in this sprint/iteration, change the existing story to add the new scenario, then recheck your workload and remove one or more stories in low priority if it is necessary.

Tools

• The company provides the options of tools and let the team make the choice.

Summary

Start the Agile journey by changing a big batch to small batches, focusing on releasing early and reducing the lead time of requirement. Teams can get better planning with a better understanding of their capabilities by changing the working process. However, the software delivery is not just about the management, it also needs technical capabilities to support the team to make better quality so they can reduce more unplanned time and deliver faster.