Path to Agility, Recognizing the Problem

So you are thinking about your current Application Lifecycle Management process and want to make a change. Maybe your organization has entrenched processes that use very specific methods in completing your daily work. This provides the team with a process but can suppress creativity and productivity. On the other hand maybe you are part of an environment that has very little process and you are dependent on key individuals in getting work done. This makes your team susceptible to individual burn-out, manual mistakes, and can be chaotic at times. Eventually you realize there has to be an easier way. You want to implement Agile, but how and where do you start?

The ALM Rangers have devised as series of blog posts to help guide you in your transformation to Agile. Each blog post will cover a specific milestone of the transformation process. In this post today we are going to cover the first topic, Recognition.

Before Getting Started //

Before you start diving into the details you need to find yourself the right advocate(s) to see this process through. Many times leadership will put forth a directive of "going Agile" but the right people are not put into place to make it happen. You need to find individuals who are passionate about software development, recognizes the need for change, energetic, and have the bandwidth. Changing any process can be difficult and the internal culture can grind things down from time to time. Your advocates need to understand this with the patience to keep moving forward.

Recognition //

In today's ALM world it takes a village to successfully develop an application. Development teams are no longer a separate entity or silo in the business. They must work together with many other stakeholders inside the organization in order to deliver a high quality application that provides value to your users. Stakeholders can range from CEO all the way through the organization. Typically many of the problems you encounter are a result of communication issues between the different teams within your organization. The reason I bring this up is to stress the importance on the roles and contributions that everyone plays in delivering software.

 

The first step in the process is recognizing the challenges the organization currently faces when delivering software. I have found that one of the best ways to accomplish this is a white board session with all of the stakeholders and have a discussion on what tasks and events are effecting their particular roles. Ultimately you would have folks representing each role all in the same room together. However, sometimes team dynamics and culture make it more productive to interview the groups separately. The goal is to find out what each role does and the pain they experience during the process. Stay away from pointing fingers and focus on the process. One exercise that is very helpful is to have each role draw out the ALM process on a white board. Map the tasks and handoffs and label the responsible parties accordingly. You may be amazed on how different each group understands your current process

Below is some examples of questions to help move the conversation:

• Are user expectations being met?
• Are requirements thorough and provide the information your development team needs?
• How do the groups and roles communicate between themselves?
• How do the teams collaborate and solve problems?
• What is the quality of the delivered software?
• How often does the user provide feedback?
• Does the development team have the tools and resources needed to successfully build software? Roadblocks?
• How is testing getting done? Who is doing it? Manual or automated?
• How does the software get released to your users? How are do we manage change requests?
• What is your desired delivery cadence?

 Another approach is to ask the roles to identify what they would like to see improved. Create an ALM wish list of sorts. 

What do the stakeholders want?

• High quality software
• Dependability
• Software that meets the requirements

What does the development team want?

• Requirements that are clearn and understandable
• Fewer interuptions
• Continuous User feedback

What does the testing team want?

• High quality code from developers with visibility of unit testing
• Efficient methods of testing including test automation and continuous integration
• More time to do exploratory testing
• Completed features

As the dialog opens up you will more than likely have a comprehensive list of things that each role in the process would like to see improved. It is important to get concerns, challenges, and suggestions out in the open. Your "Agile Advocates" will need to address these items when researching and proposing new processes. It also adds a level of transparency and involvement with all your stakeholders and team members. If folks are not involved in the process from the beginning , you will probably get more resistance when trying to implement change.

In our next entry we will focus on learning about agile practices and educating your teams and stakeholders. We can then map out the new processes and how the pain points will get addressed using agile practices.

Resources //

Try taking an ALM assessment to help identify points of change in your teams process.

vsaralmassessment.codeplex.com

www.microsoft.com/visualstudio/local/uk/alm-assessment

Comments

• Anonymous
  October 29, 2013
  The comment has been removed
• Anonymous
  June 10, 2014
  Great summary!  Thanks this will be useful.