7 Ways to Embrace True Agility in Software Development

Agile is a methodology that traditionally has been popular with small and medium size organizations and projects, and has recently become much more mainstream in large enterprises. This trend has raised questions around how do you manage your project teams as you scale to larger projects, teams and locations?  Do you take the same pattern and process and simply “scale up”?  Or do you take a different approach.

These are questions that we’ve had to deal with as we head into a period of new growth for Intelliware.  We used our 15+ years of experience with Agile to come up with some key recommendations to consider when you scale Agile to larger projects and organizations.

1. Make sure your team is right first, and let them own the process. Agile focuses on people, so before embarking on your Agile journey it’s important that you have the right people on board first. Make sure team members understand the basics of Agile and want to work in an Agile environment, and that the makeup of the team is cross-functional and staffed with developers, business analysts, quality assurance analysts and any other roles that are needed. Once you have the team in place, and this is key, also make sure they have the freedom to make Agile their own. This means that when moving to Agile it’s imperative to give your team members the ability to tweak their process so that they can work how they work best. Arlen Bankston of lithespeed says this:

Fundamental to all agile methods is the idea of autonomy at lower levels, such as a team in Scrum/XP, or a group of aligned individuals in Kanban. The ownership that this drives keeps teams more engaged and interested, while also speeding the process of evaluating and executing decisions.

2. Make sure information flows both ways in your organization. Feedback is a key enabler of the Agile approach. Frequent releases to end users provide opportunities to get feedback which can lead to more informed decisions and increased focus on business value. When we did frequent releases at Intelliware with our devOps team, we realized it was to ensure we could PLAN better. The feedback we received from end users working with our releases helped us make better decisions on priorities for future features.  It’s important to make sure that user feedback is assessed immediately and shared up, down and laterally.

87% of the 10th annual State of Agile survey respondents said that the “ability to manage changing priorities” remains as the top improvement result of implementing Agile practices. This requires a loosening of the corporate ego strings; projects may be scrapped, timelines may be disrupted and decision-makers may have to settle for less of what they thought they wanted in return for what they actually need (which ultimately will be more valuable). Remove hierarchy, traditional communication structures and replace them with flexibility as well as curiosity.

“One of the major benefits of Agile over waterfall is that you see a deliverable on an iterative basis and the Product Owner can decide to make changes to the product backlog.” – Sudhakar Gorti, CIO, Environmental Data Resources.

3. Go big or go home. Your entire organization needs to buy into the Agile methodology or it could fall flat or never reach its full potential. McKinsey notes (within the enterprise) fewer than 20% of companies using Agile consider themselves “mature adopters,” with widespread acceptance and use of Agile across business units. Meanwhile, the companies that are deploying Agile at scale across the enterprise have accelerated their innovation by up to 80%.

Could the lack of Agile adoption in the enterprise be due to the siloed nature of many enterprise companies? Traditional yearly budgeting, separate departments for developers and testers and application focus rather than holistic product focus are all Agile KILLERS. So do the opposite. Keep hierarchies flat, remove barriers to approval and testing, focus on the team and encourage local innovation.

*Note: it is possible to encourage autonomous teams with different Agile methodologies while steering a company toward holistic Agile methodology and keeping innovation central.

4. When starting from the bottom keep to the basics! If you expect to be able to implement Agile from the top down, you are in for a rough ride. Agile transformations require air cover from the top, but really only take root when they are adopted from the ground up.

Train your Agile teams from the ground up in Agile methodologies and aim for the key “building blocks” of Agile; that is, focus on the values and principles of the Agile Manifesto and, as mentioned above, allow the team to figure out how best to implement the practices themselves.

5. Get everyone on board. There are plenty of horror stories out there about how badly some have failed at implementing Agile enterprise-wide, enough so to make skeptics of even those who put stock in the benefits implementing Agile can provide like:

• Improving overall IT delivery
• Transforming IT business relationships
• Shortening time to market
• Increasing customer satisfaction
• Lowering development costs

In an enterprise setting make sure that both the development team and the larger organization are onboard with the Agile approach. This means that other stakeholders outside of the team, such as the steering committee, project sponsor, legal department, infrastructure group, human resources, etc. will also need to change the way that they work and become somewhat Agile themselves in order to support the development initiative.  If these outside stakeholders are not willing to work with the team’s Agile approach then the team could end up wasting time on external dependencies that they don’t have a lot of control over.

6. Use what works for your organization. Agile is usually a good approach for building business software, but it’s not a “one size fits all” solution for all projects. According to Gartner, different classes of development problems will require different approaches. And Agile is just one possible approach. Traditional methods (like waterfall) may work on projects that have clear and fixed requirements and established, well understood technologies. Agile, while it can still work in these projects, may not show the same amount of ROI. Many companies have flourished with a mixed methodology whereby all departments learn and become trained in an Agile methodology but only use it for the projects that need it.

7. Know what you’re getting into. Make sure you and your team understand what they are getting into. Agile has many benefits and there are a host of reasons why companies are investing in internal training, human capital and specialized consultants. However, none of these steps should see the light of day unless you understand what the Agile methodology IS. The technical executive editor of Information Week puts it this way:

At its most basic, Agile development is development that adheres to the principles stated in The Agile Manifesto. More broadly, Agile is the word for an environment in which the priorities, according to the authors of the manifesto, are:

1. Individuals and interactions over processes and tools;

2. Working software over comprehensive documentation;

3. Customer collaboration over contract negotiation; and

4. Responding to change over following a plan.

Agile software development can be implemented in a number of ways, including scrum, kanban, scrumban, extreme programming, and many more. At its heart, Agile is a change in the way of thinking about development. It’s a change so profound it sometimes spreads to the entire organization, leading to Agile HR, Agile marketing, and a wholly Agile company.

If you’re not ready to commit to that very simple definition above, Agile is not the way forward for you; whether you think you’re Agile as a company and are simply looking to scale that agility or whether you’re trying to effect change from the middle out.