Top Up, Scale Down!Gurpreet Singh
schedule 2 years agoSold Out!
Every Company is trying to surpass its Competitors in this ever changing World. Today, World is changing so fast, that every company needs to Iterate faster after reading the Customers’ insights. The transition happened from the Industrial Age to the Waterfall Age. The Waterfall resolved the concerns to an extent; however, it laid the foundation for a new set of issues. Then the focus shifted to RUP, Spiral, V models and finally to Scrum, XP, Lean, Kanban, Scaling Agile, etc.
However, no framework or methodology can solve the concerns without having a Good Engineering Culture. The Culture undoubtedly consists of People and the surrounding Processes & Practices to help them (& not act as Blockers) to achieve the ever changing Definition of Success.
In this context, this talk will emphasize to shift our focus from the Leadership-Powerpoint Slides to our Engineering Culture. It will highlight the Problems and an attempt to answer the same by taking good case studies of Companies like Spotify, 3M, etc. We will talk about philosophies like M3.0, Holocracy, Tribal Leadership, etc and Engineering practices like Pair Programming, Continuous Integration, etc. We will also focus on the Roles of PO, SM, Developers, UX and the Leadership to shift to better Engineering Culture for the overall success of the Employees, Teams, Products and the Company on the whole.
Ina a nutshell, this talk underlines the importance of Alignment of Leadership’s Vision with Actual-on-the-ground Engineering Culture to achieve a Win-Win situation.
From Agile to DevOps -- The journey we had and ahead of usJiun-Yang(John) Hsu
schedule 2 years agoSold Out!
In IBM we have adopted Agile for several years. While we thought we were good enough, we can actually do better with DevOps. Our release cycle was 6~12 months, and that's far slower than standard DevOps teams. So we decides to adopt DevOps about 15 months ago. However, in a huge company like IBM, adopting something as big as DevOps is very difficult. Our experience with Agile adoption gave us a pretty good idea that this is not easy. But this is what we must do, and we can afford to fail. So, we did the following:
- Made a lot of changes in the process and organization. For example, merging functional test team with development team. We also adopted many new processes within the development teams
- Worked very hard in getting the support from managers and executives of all levels. This is probably the most important thing for every company who want to adopt DevOps, and we definitely had to spent a lot of effort to make sure we have this.
- Delivered many educations targeting every roles in software project. We delivered various education sessions to different roles, like developers, testers, and managers.
- Learned and explored knowledge and tools. We have specialized team working on investigating tools and studying DevOps related knowledge, and share with everyone.
- Invested tons of efforts in developing automation tests of all types, as well as modifying existing automation tests to fulfill DevOps requirement.
- Greatly improved our build process and scripts. We have a centralized build team helping us do this, and each development team also worked on improving their build scripts.
I'll share what we did specifically in the areas above. As always, this is a continuous improvement and continuous learning process, and you're never "done" with DevOps. So, I'd like to discuss some topics that we don't have an answer as of now:
- Centralized build team or not? Most DevOps practitioners will say no to centralized build team, but large companies like IBM all have super complicated compliance that applies to build machines. If we don't use the service of the centralized build team, the product team will have to handle the compliance, which is not fun at all.
- Find and fix every single defect before releasing to production, or move that effort to production environment monitoring and improve the recovery process of the production environment? This is especially valid for system test, where the multiple days long run is needed to find some bugs. Those tests can only find about 20% of defects, so is the result worth the effort?
This topic should be very interesting for those who want to or just started to adopt DevOps in a relatively large organization. Applying DevOps in a web startup is what many people had already done. Applying DevOps in a large organization with on-premise products and huge amount of legacy codes and tests is a very different story.