What's missing? Why can't we release faster? Are we doing the right things? In this video, begin to map the value stream, look for waste, and look for ways to improve, refining the process where it makes sense.
- We were a couple months in as we got some runtime in on our new way of working and we started to measure our improvement, we needed to figure out what was next. - [Peco] That's right, it was time for our second planned, do, check, act loop. We picked some known practices as a starting point, but now we needed to analyze what was working, what wasn't, and decide on our next experiment. - [Ernest] We developed a process of sorts, and let it emerge from what seemed to work for the team, but now it was time to analyze it. So we created a value stream map, showing the flow of our process from the product manager defining the requirement, how long they stay in the backlog, coding time, build, QA, and so on, until finally deployed to the live customer site.
- [Peco] When we looked at the areas of waste, the biggest bottle neck in the concept to cash path, was that the final code sat around for up to six weeks before getting released to production. We'd already realized that it iterations didn't always match up with our release cycles and that was okay. Even though releases were performed every six weeks in sync with other IT teams, our iterations were every two weeks, which provided much more grandlar milestones. - Well we thought why not release at the end of every iteration? That's what the kids do nowadays we hear. - Everyone was on board, so we released the next version at the end of the iteration.
- And that's when it all went bad. We had an intermittent production outage that lasted for days, print jobs got eaten, and we weren't even sure which ones. We spent most of the next sprint fixing the problems and doing a lot of damage control. - Apparently, we needed to build some more things before we were ready for this, but what? The developers blamed QA and Ops, QA and Ops blamed the developers, not only making it hard to figure out where we went wrong, but also causing a very real setback to the team spirit we've been building.
- Yup, we needed the whole team to take responsibility and actually solve the problem. - [Ernest] That's right. Lean and Agile management is much less about directing and a lot more about empowering the team and setting them up for success and letting them do it. - There was a bit of back and forth in the team, we realized that we had communication issues that the stand ups didn't really fix. And once again, our code quality was just not up to par. - That's right, it's important to mention that our cross functional team, while they were all working on the same project, were physically sitting in different buildings and some were also in different non-overlapping timezones.
- To improve communication, we setup a multi user chat app. We chose Slack for this, and created a project channel that included everyone on the team. Questions could be asked by anyone, and often they were answered instantly. This was immediately beneficial. A number of folks on different teams often had the same questions and it drastically cut down on the amount of time needed to get a response. Ernest and I would often jump on the channel and answer questions as well. - Something we didn't anticipate was the team moral also improved from having a team chat.
Some of the folks hadn't worked together in the past and having an avenue to communicate with each other, helped to bring the team closer together. - [Peco] We also did some collaborative team building. We flew the remote team members to HQ and had everyone at the same location. - [Ernest] Since we're based in Texas, these team builders were largely meat and gun based, but do what works for you. Out in sunny California, it could be sushi and surfing. - But probably not at the same time. - No that's probably an unwise combination.
Brings sharks. - We also presented this problem as something for them to solve with our support. Breaking through complacency is one of the hardest parts of moving to an employee first culture. - It was very tempting for us to jump in with our own ideas on how to fix things, but part of the difficult transformation is to teach the team, to own and work through continuous improvement themselves. We let the natural change agents in the group emerge and we encourage them to concentrate on this new constraint.
- They came up with some ideas, and then came up to us and said, "Okay, we're not exactly sure how to do some of this stuff. "We need better automated testing, "and a release process. "We could probably learn some of this off the inter webs, "but learning all of that from scratch "is going to be slow and error prone." - And we expected that to happen at some point. You can't always just do a whole new thing without some expert help. So, we hired a dedicated DevOps release manager, a lady with a lot of experience with kind of thing under her belt.
- We were ready for our second phase of building. So come back and join us in the next video to hear about it.
- What is agile?
- What is lean?
- Measuring success
- Learning and adapting
- Building a culture of metrics
- Continuous learning
- Advanced concepts