Rawpixel - Fotolia
Agile characteristics for internal software development teams
Not all developers create software for external users. So, what lessons can internal dev teams learn from Agile? Start with one problem at a time and iterate from there.
So much Agile advice is aimed at developers at the proverbial hub of the software universe, the ones who produce packaged software, hosted applications or SaaS as a revenue-generating product for the business. What about the rest of us?
Agile promises faster software design, development and testing, accomplished more efficiently and with less documentation than under a Waterfall methodology. Agile characteristics include team structure, tools, communication and app architecture. The approach means composing applications as discrete components that can change independently. And software teams morph into self-organized groups of people with the skills and roles to work on them concurrently.
The benefits of an Agile approach are clear for companies that sell software, but another group is prevalent throughout both the corporate and nonprofit worlds: internal software development teams. These teams typically include a dozen or so professionals who do everything from troubleshoot functions to provide training for a few hundred internal users. Some internal software development teams customize commercial off-the-shelf products for their organization's use. They rely on a vendor's SDK to add necessary functionality without dumping cash at the vendor's feet and engaging in a professional services contract.
Some Agile characteristics help those internal dev teams that do not build software from scratch. They need to latch onto iteration, a concept at the core of Agile. Iteration is the ability to take some small steps at first, make adjustments and move forward.
How to adopt Agile flexibly
As a first step into Agile, an internal software development team should identify and fix the problem spots in their existing processes.
Find out where things break down in the process -- even if those spots are not particularly related to how the team writes or tests code. To characterize the most problematic tasks, list each one and assign it a score. Start with the task that gets the worst score. Do some group brainstorming to come up with a corrective action plan. Avoid making that plan overly detailed -- it just might defeat the purpose.
Try applying core Agile characteristics, such as less documentation or more focus on the user, to generate process improvement. For example, if an internal software development team struggles to gather realistic requirements for customizations on a product, write user stories to address that process problem, rather than a full-fledged business requirements document. Then, see whether the Agile approach eases or improves development and testing.
Additionally, overhaul testing so that the task takes less time and becomes less rote. A Waterfall team might create test plans by filling in a boilerplate template. The QA team finds this step problematic and time consuming. Replace it with a matrix of test conditions, and link those cases to a requirement embedded in one or more user stories.
Remember that the main Agile characteristic for internal teams is iteration. Apply these process tweaks to a single enhancement request and make it the first iteration of the workflow redesign.
Don't worry if the team stumbles a bit. The human capital investment isn't lost because the entire team gains practical exposure to Agile concepts.
Understand Agile in context
The Agile Manifesto is a framework for redesigning existing processes and workflows with a suggestion for where to put some emphasis. The Agile Manifesto, written in 2001, built on previously established concepts. Reengineering the Corporation published in the 1990s, and just-in-time manufacturing with Kanban, a tool popularized in the 1940s, both influenced the methodology. Agile teams today use Kanban boards to organize software development and testing.
Iterate, and reiterate
Once each Agile-based enhancement deploys, gauge the success of this iteration with a retrospective/lessons learned gathering -- another characteristic of Agile. Discuss what did and did not go well, and then use this information as the foundation for the next iteration. Keep iterating on this problem area until the team is ready to take on the next one.
A Scrum master or Agile coach can help work through the jargon associated with Agile characteristics -- standups, burndown charts, epics and stories -- but one is not really needed.
For developers serving internal customers and working with commercial software, a formal change to an Agile team structure is not necessary. Ensure that the team is manageable as it is. In many organizations, the team size is probably small already.
