Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Building an agile team: Go from fantasy to reality

public://pictures/idan_twitter.jpeg
Idan Bauer R&D Group Leader, HPE Software
With larger software development organizations, agile is their fantasy, waterfall is their reality. Why do they have a hard time building agile teams? This article describes seven imperatives that can help make a difference.
 

You may think you're part of an agile team, but there's a good chance that's a fantasy. This was the situation in my organization when I arrived from a startup environment that had a much better understanding of agile. In my new organization, a large enterprise, people thought they were agile because they had reduced their development cycle from four weeks down to two-week sprints. But in fact that was a fantasy. The reality was that their drop cycle was still four weeks long, different teams were dependent on each other, and releases were still being planned six to nine months in advance—then getting delayed. Sound familiar? Are you hearing the roar of water as it quickly loses potential energy?

So what does it take to be agile? In my opinion, there are three main requirements:

  • Be in the cloud. This facilitates a quick feedback loop every time you release a new version.

  • Work on a single product/version. This allows the team to stay focused.

  • Deliver frequently. This lets you receive and react quickly to feedback you get from customers (thanks to being in the cloud).

Why do large organizations have such a hard time building agile teams? The main reason is that these organizations typically have large development teams that depend on each other; one group can't not deliver functionality that's truly "done" before another team has delivered theirs. Another big reason is that large organizations have a hard time operating in an uncertain environment. They need to project far into the future and plan releases at least six or nine months ahead. Yet another reason is that large organizations don't like being told what to do. They make product decisions based on their own (supposed) expertise.

By contrast, being agile means you're much closer to customer feedback, and you should let it guide you. But I'm getting ahead of myself. I started this job with the challenge of turning the agile fantasy into reality, and I began the effort under the condition that I would be given free rein. Here are the seven imperatives that guided me in building a more agile team:

1. Get support from management

You can't implement big changes in an organization without support from the people in charge. You have to talk to management, explain what you're doing, and outline the benefits they can expect to see. Make it tangible, and set measurable goals that your managers will appreciate. Without their support, you'll lose before you start.

2. Plan short term and commit less

I refused to give long-term estimates and committed to a minimum functionality (like a minimum viable product) and left the rest of the functionality open to debate, saying I would revisit it if time permitted. At first, this caused general panic in the organization, all the way from management to developers and testers because people felt like they didn't have a foundation to stand on. What they didn't know was that I would probably deliver more than I initially committed to. Compared to other groups on a six-month timeline, my two-months-ahead commitments still gave our team four months to play with in the backlog. These short delivery cycles meant that I had the flexibility to make a delivery, get customer feedback, and change the backlog accordingly for the next delivery. My becoming-agile team ended up delivering more functionality, which was more relevant and truly "done."

3. One group delivers the product

There used to be a distinction between developers and QA. This created problems because developers would—supposedly—complete a user story and pass it on to QA for testing, only to have it promptly thrown back at them for bug fixing. My agile team includes both QA and developers working together toward a common goal, and quality is everybody's priority. So if the QA workload fills up and there's more testing to do, development will stop, and developers will pitch in with QA, whether it involves manual testing or writing automation tests. This worked very well on my team. In fact, it was so effective that at one point, QA started to relate too well to developers and slipped back to testing everything that was passed to them, losing focus on the big picture. Now, there's an internal separation within the group. While QA is an integral part of development, two testers act as external auditors, reporting to the QA manager, and work more independently to decide when developers should pitch in with QA. The result is that on my agile team, QA is more engaged in the features being developed, and developers are more engaged in getting their user stories truly done.

4. Don't wait for anyone

My team works on an application that consumes platform services through an API developed by another team. This created an unhealthy dependency: My team was getting stuck with features, losing focus, and losing momentum while waiting for the API to support those features to be ready. To break this dependency, we started implementing our own comprehensive API stubs. This really got things moving again, and today we have a server that implements all the platform APIs we need to progress with our own code.

This had two positive effects. First, application delivery used to lag behind platform delivery by two or three sprints. Today we deliver two or three days after the platform team. Second, we're able to identify problems with the API while it's in development, and provide that as feedback to the platform team. Our surrogate API was so successful that other teams started to use it, and today, it's widely used by all teams working on the product. In fact, until the real API delivered by the platform team was mature and robust enough, our API stubs were the only way to make the application work.

5. Transform teams from layers to features

Typically, enterprise software is developed in clearly distinct layers by different groups: server, application, and UI. I decided to take the previous point a step further: When necessary, my team took end-to-end responsibility for the whole feature and started developing server functionality that we needed to progress. At first, I took a deliberate hit on velocity because it takes time for developers to learn code that isn't in their area of expertise or comfort zone, but this bore fruit in the long run. Once the team became feature-oriented, its members were more well-rounded and had capabilities in new areas of software development. Some developers even discovered they had affinities in new directions, and I was able to encourage them to work on the projects they're most drawn to. Overall, the team became more productive, and within three months we saw incredible improvements in what they could deliver on both ends of the stack.

6. Don't over-deliver

Enterprise groups typically write code with generic infrastructures in mind so they can accommodate any future requirements that comes along. There are two problems with this approach. One is that many of those future requirements that the infrastructure supports never actually materialize, so a lot of effort is wasted on planning and developing unused features. The other is that it produces a lot of code that's never used, which leads to code rot. Yet, the teams still have to make efforts to maintain the code as development progresses.

My team used to plan features for cycles that ranged between 200 and 400 days. As a hopelessly optimistic bunch, they typically committed to delivering way too many features. The end result was either that they didn't manage to deliver all the features they had committed to, or worse, they delivered all the features, but in poor quality. Today, my team only delivers exactly what's needed at the end of any particular sprint. No generic infrastructure, no guessing about future requirements. We focus on here and now, only delivering according to the required specifications.

Focusing on just what's needed for a given sprint presents two major benefits. First, all the code that we write is actually used because it was written to answer a specific, concrete requirement. Second, when requirements change—something an agile team should expect and we do have to refactor our code—we have a better understanding of the requirements, and consequently produce better code that more precisely answers the need.

7. Lead by example and empower your team

If you want the respect of your team, especially during major transitions, you have to get your own hands dirty and empower your team to work independently. My team leaders and I all write code. We don't touch mission critical code because we're not "in touch" with the code base enough to know its finer details, but we do work on side projects. This helps me and my team leaders be more engaged in the development process, and fosters a team spirit among the developers. In my agile team, developers are as comfortable assigning bugs to me as I am assigning tasks to them. We're a close-knit team with a flat hierarchy.

I have complete faith in my team, and let them manage the day-to-day issues independently. On the rare occasion that we have a standoff, I may have to pull rank and make a decision, but for the most part I let developers choose their tasks and do what they like the most. Not only does this give all the team members a sense of belonging and ownership, it also frees up my time to manage the higher level issues of steering the team in the right direction. On the whole it just makes the team much more productive.

Two reality metrics

There are two main metrics that show how the fantasy of my agile team has become a reality.

The first is our delivery rate. The number of user stories my team delivers has gone through the roof. We met all of our commitments, including all "stretch" goals, and took a product from scratch to delivery within five months—an impressive pace for an enterprise product. Now, in our second iteration, we find ourselves chasing after product managers to deliver user stories for us to work on.

The second is that the number of known defects in a release has gone down to 20 percent of what it used to be. The team is more engaged and conscious of quality, delivering better code rather than just churning out user stories. We're meeting and even surpassing expectations delivering quality code that's always in a shippable state.

Keep learning

Read more articles about: App Dev & TestingAgile