Agile Methodology in Software Development

Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

Source – devops.cioreview.com

Speeding the delivery of technology is a critical aspect of business today. One of the approaches to increase that speed of delivery that many of us have worked to implement is the use of Agile software development methods such as Scrum XP to deliver business value more rapidly. Transforming an organization from a waterfall centric methodology to agile development is an exciting, but difficult time in an organization.  The changes that are required to the organization are not just mere IT department or technology changes, but require broader organizational change management to successfully advance how technology is defined and delivered to an organization.

This article won’t go into the details described in the original Agile Manifesto written in 2001, as this isn’t about describing what agile is. This article characterizes three of the things that fueled the transformation of this organization on our journey from waterfall to agile.

1. Organizational buy in is essential in the move to Agile.  This requires ongoing and consistent education and communication more than anything for the various stakeholders to truly adopt this change. We did multiple types of training to make sure that we covered all the appropriate parties. Large group training for the teams that will form the scrum teams and will be the backbone of development is a must. Those teams must understand the what’s and why’s of how to successfully deploy scrum in their projects. They will be the ambassadors of success to all other areas of the business, so they need to have broad and deep knowledge of the process and ceremonies in Agile. Training all the other groups that interact with the Scrum teams is a must to ensure everyone is on the same page and have same level of understanding. We had separated sessions for many of the groups including Product Managers, Product Owners, Executive teams, Infrastructure and Operations teams, Architecture, and our business process owners. We tried to ensure that each of those groups had a somewhat custom version of the training, to understand broadly what the basis of Agile is, but more importantly to understand what their role is in our Agile methodology. These training sessions have created the base of knowledge and understanding showing the positive impact that agile can have. The communication campaign creates positive buzz across the organization and a willingness to not only assist in driving this forward, but to champion the cause.

  ​Delivering visible results builds momentum and motivation to keep driving the change 

2. Delivering visible results builds momentum and motivation to keep driving the change. The basis of the move from Waterfall to Agile is delivering incremental business value in very short time frames as compared to a more solution based waterfall approach. As the teams start to scrum and develop using this methodology, one of the key aspects is the concept of delivering usable product in every release. If a team is working in a typical 2 week sprint, this capability is not going to be revolutionizing or earth shattering but it is essential for business partners to see the value that can be produced in such a short time frame. A key element of change management is building trust with our business partners that things are moving in the right direction. These incremental deliveries allow the business to see in near real time what is being delivered, how it is going to work, and the benefit that either they or the external customer will see from it. This is fundamental in creating the right relationships for success of all parties.

3. Viewing functionality as a solution versus a technology slice. As we continue to think about the most efficient ways to create value for the business, bringing some Lean principles into the development cycle changes how we structure teams and create work queues. Historically, a development team would be functionally setup with developers only (Java, C, C++, .Net, whatever the language of the day is). The business analyst would gather requirements get them approved and deliver to the development team for coding. Infrastructure, integrations, databases, and other aspects were considered separate tasks or items to be completed and in some cases, would be totally separate projects. They would be given their requirements and drive forward to deliver the requested functionality. Creating the technology team as a “tiger team” or other cross functional team changes the team dynamics and changes speed and accuracy of the delivery. This forces the team to think of the solution in an end to end manner, better understand dependencies of other technology areas, improve handoffs, and reduce queuing between teams. Meetings are reduced; questions are answered sooner and in some cases figured out during the collaborative design sessions, which all create a more effective working environment for the teams.

The unexciting truth of how to achieve success with an agile methodology is using the same recipe as many other business or technology projects. Communicate to the right players, build the right teams, and deliver on commitments. Doing these things while implementing the right agile ceremonies for your set of circumstances can lead to great things for your organization.

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x