Build an Agile Organization and NOT a bunch of Agile teamsRANAN BHATTACHARYA
schedule 4 months agoSold Out!
The benefits of evolutionary iterative development have led to most of the software development organizations adopting Agile. In reality, however, many enterprises are facing the challenge of not producing the expected outcomes even after adopting Agile. The key reason for this is the failure to optimize the flow of the whole system.
Although the overall trend of Software Development projects looks way better after moving towards Agile and DevOps, recent surveys show that 55% of the Agile projects are still not delivering the value they aimed for.
This is a clear indication that the way IT programs are run worldwide is still flawed. Huge wastage and rework are involved due to delayed integration of pieces between different parts of the system.
In today's scenario, organization have appreciated and acknowledged the need of DevOps to become Agile. But in reality, DevOps is used only to bring in efficiency in parts rather than bringing all the teams together for seamless integration. Teams are working on setting up Engineering tools and practices to make their delivery faster. But they still struggle to reduce the end-to-end lead time between the time an idea is conceptualized and the time when the customer receives the functionality for use. The primary reason for this problem is the differences in priorities of the linked tasks in the backlog of various teams. Hence although all the teams are claiming to have delivered the tasks 'as per plan' but all these pieces are not completed when needed by the other dependent team. Unfortunately, the partially completed parts of the Epic developed by project teams have to wait for the availability of portions assigned to other project teams for further integration. Since other project teams may be busy working on another part of another Epic, the end user’s waiting gets elongated to get the requirement delivered completely.
Hence Definition of Done for an Epic should include the end to end Continuous Integration. Achieving Continuous Integration and Continuous Deployment at team level do not guarantee 'Continuous Delivery' to the customer.
Now think of a situation in which these project teams come together and work collectively as a program to deliver a complete working solution. In this structure, each functional group allocates the needed people to one project. These team members form an Agile Program consisting of cross-functional project teams to produce working software iteratively. Agile program's responsibility will be to define the value streams consisting of Product Owners, Architects, Developers and DevOps people. This will ensure that all the needed teams are in sync to develop a solution which will deliver the desired value to the customer. Architects, Product Owners and the DevOps engineers should be involved at the program level from the beginning. It is counter-productive when these people work in isolation at the project or team level. DevOps should be incorporated with the focus on optimizing the whole system and not being just focused to improve a team's velocity.
How We Get Agile Transformations Wrong By Trying to Do It All So RightHoward Deiner
schedule 5 months agoSold Out!
Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.
Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.
But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?
I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can't logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.
This session will speak to the specifics of the whats and whys.