Learn to improve the agile processes by enlisting basic metrics. Get a definition of "done" to start understanding how the process is doing and see progress with demos at the end of iterations.
- [Man with Glasses] As we moved into our first phase, we knew that we needed to measure our results so that we could evaluate our progress. - [Male Voiceover] We started using a kanban board to visualize our ticket flow. We used a software version so the whole distributor team, could see it. - This helped everyone see what others were working on. If we were doing well towards our iteration goal and so on. - As we progress through our first few sprints, we had trouble shipping working software. My developers were releasing buggy code. - While we had a CI system that compiled the code, the functionality being tested would often have run time issues that were found during the test cycle.
Carthic sat down with the development team, and they talked through better habits to write cleaner code. And they decided on three things to improve the issue. - First, code checked in would be accompanied by unit tests that the CI system would run after it built the code. Second, we'd allow only short lived branches of master. One ticket ideally a day or less. Finally, old branch merges to master had to be reviewed by somebody else in the team via pole request. More frequent check ins and builds finds problems more quickly.
And allows for more easier debugging of what went wrong. Build fails are okay if they're helping you fix things. - Chat was used for code review requests. And if everything looked good, it was pushed pack into the master branch. These steps help the development team deliver stable code to the testing and operations group and made the process more smooth. - We also discovered that there was confusion around ticket states. Specifically, what does it mean when a task is done? Development was used to a task being done when code was checked in.
And ops thought it should be done when the code was deployed to production. Our work flow at the time was very simple with three states on our scrum board: To do, Doing, and Done. So the developers would complete the work to develop a feature and push the ticket to the done state. - Initially, we championed simple work flows but when we realized this was actually hindering our ability to deliver, we allowed for a few more steps to the work flow. - As a result, we added another stage to our scrum board ready to test.
Our work flow no became To do, Doing, Ready to Test, and Done. Soon enough though, we ended up having a work flow of To do, In Development, Ready to Test, Ready to Deploy, and Done. With the final work flow everyone agreed that a task was done when it was deployed successfully to production. - Finding a work flow that the team was happy with took a few iterations. - Our next hurdle was more of a product management issue. We realized that the team was starting to pick tasks from the To do pile in no specific order.
A developer would pick the easiest or most interesting task, while operations would frequently pick urgent issues like break fix that didn't necessarily help us get ready to release our new product. - To mitigate this, Ernest and I would sync up before each iteration to make sure that the To do list prioritized. That way we endured that the team was delivering the right value at the right time. - Further, we ended up adding goals for every iteration. So that we could see whether we were on track for delivery or not.
- At the end of each iteration, we'd refer to our goals and see our accomplishments. The team would also demo their completed work. This was a good way for everyone to see what work was done and watch the product come to life. - With better communication and updating our work flows and process when we saw issues, we started to witness results and stronger team camaraderie. - But were we just in a bubble? Would it last? Would we be able to make our release in time, or ahead of schedule? We'll look more at this in the next section.
- What is agile?
- What is lean?
- Measuring success
- Learning and adapting
- Building a culture of metrics
- Continuous learning
- Advanced concepts