The early part of the 21st century saw the rise of agile software development. It was quite prescriptive in nature, almost to the point of being religiously dogmatic. “Individuals and interactions over processes and tools,” the original manifesto declared. “Working software over comprehensive documentation.” “Responding to change over following a plan.”

If you’re not doing pair programming, or Scrum, or Extreme Programming, then you’re not agile, the pundits cried. It was all or nothing.

Now, some 12 years after the manifesto was written, agile has crossed the chasm, going from a grassroots movement into the mainstream. And today, organizations are looking for maturity in their agile development processes.

But the question is, what represents agile maturity? How do organizations know how far down the agile road they’ve gone? Several organizations have released maturity models for agile adoption, and they mostly agree that agile maturity means scaling the process beyond a team level.

Microsoft is focusing on the ability to scale agile to all stakeholders of a software project, but without dictating how to do that. It’s what the company is calling “agile your way.”

Agile’s up above it
Aaron Bjork, project manager on Microsoft’s Team Foundation Server team, said, “I think we’re entering a period where teams want agile maturity, but I think agile maturity comes with scaling it, and you can no longer just be a team within an organization and say, ‘Well, we’re an agile team and we’re successful,’ because now you’ve got 20 agile teams, or 10 agile teams, and success is not defined by a single agile team being successful, it’s defined as all of us doing this and being successful, so I think that’s the new challenge.”

Bjork described agile at the team level as science, but scaling it up the enterprise is more of an art. “I’ve often described it as, at the team level, there’s a lot of science you can apply to agile. I think Scrum is a science. Here’s how you do it. There’s a formula. You break it up into iterations, you have a backlog, you have roles you can apply to it,” he said.

“People can grab it and accept it and follow the prescriptive guidance, the science if you will, and be successful. Above that, I think there’s a lot more art that has to take place, because as you move up in an organization, and you’re trying to make stakeholders happy, trying to make leadership teams happy, you’re dealing with personalities, you’re dealing with people that have strong opinions, that have built their careers maybe doing things a different way, so I think maybe you have to apply an art form to it, and I think that’s sort of where ‘agile your way’ or ‘agile on your terms’ is coming out.

“I think making agile successful at that level can’t be prescriptive. It has to be a little more flexible. I think that’s where we’re at in the industry, trying to figure out how to do that.”

There was a time, Bjork said, when you could sell agile tools to teams. But today, he cautioned, you better have a message for stakeholders. “If you think about our tooling, in the last release, in 2012, our focus was on making an agile team successful,” he said.

“Scrum was the pattern we followed, and we built tooling to support that. We built sprint planning tools, we built taskboards, we built backlog-management tools. That was our focus and that’s where we put our energy. As we move forward, our energy is now around the assumption that you’ve got lots of agile teams using that tool set, and now how do you make sense of it at the stakeholder level, at the leadership level? And that’s what, internally, we’ve been calling enterprise agile. How do you do this inside an enterprise, not just at a team level?”

The approach Microsoft has taken to engage stakeholders is to create in Team Foundation Server what it calls portfolio backlogs. “Essentially, you’ve got teams down here, and they’ve got their own backlogs, and they have a fair amount of autonomy with that backlog, but up above that, the level of detail that’s necessary to be successful with an agile team doesn’t scale to what a stakeholder needs,” Bjork explained.

“So we’ve created what we call portfolio backlogs, and we allow you to link these things together so you can have a coarse-grained view that makes sense for the level that you need. Our tooling out of the box supports two levels—several teams and a leadership team over this—and you can scale it up to this. And every one of these levels support the same principles: it supports a backlog you can order, it supports a Kanban board, and it also…allows you to customize it to meet the conversation that’s happening at that level, if you will.”
#!
Getting the enterprise involved
The struggle to scale agile through an enterprise is “a genuine issue that needs to be resolved,” said Mark Richter, solution architect at ThoughtWorks. That company’s approach is to let each department use the tools they have and are comfortable with. That, he said, will result in agile development.

ThoughtWorks helps developers using Microsoft technologies become more agile by letting them pick and choose the right tool for the job. “It’s important that developers not be tied to a particular vendor for everything they do,” said Richter. “Microsoft likes you to be wired into their tool set, but we allow you to use the best tool for the job, especially with build and deployment.”

The company ties its Mingle agile project-management platform into Microsoft’s Visual Studio, so programmers can run Mingle inside the development environment and query the work that’s on their plate for today, without having to jump out of Visual Studio to a Web connection all the time, Richter explained. Developers can create their “Mingle cards” right in Visual Studio, he said, and an Excel plug-in enables managers to query the cards and import the user stories into Excel. This helps them track who’s working on what, what the assignments are for the day, and what kind of progress the developers are making.

Richter also said ThoughtWorks offers a .NET client library for Mingle, through which Mingle data can be pulled down to a workstation client. The Visual Studio and Excel plug-ins, as well as the .NET client library, are all open-source projects hosted on GitHub, he said.

Further, ThoughtWorks’ Go tool for continuous integration integrates with Microsoft’s Team Foundation Server, enabling developers to pull source code into Go to do automated builds. Go, Richter said, has the ability to orchestrate very rich pipelines, and “visualize the dependencies and flow through whatever pipeline infrastructure you’ve created to deliver stuff. That can be across several browsers while running thousands of tests in parallel.”

Tim Miller, CEO of agile planning software provider Rally Software, also sees organizations struggling to scale agile at the enterprise level, but he thought a lack of organizational visibility is only part of the problem. The big problem, he believed, is cultural.

“Individual practitioners have always been extremely excited by agile. Teams have gravitated to it naturally,” Miller said. “But these techniques can be counterintuitive to executives.”

Businesses have long required long-term planning efforts to be successful, and according to Miller, “The people who write these heavy plans want to apply them everywhere, when in fact less planning means better software, sooner.”

He said it takes time to change a culture—perhaps years—so it’s important that businesses have the ability to pivot rather than stick to a plan that isn’t working. It’s true for development teams, he said, and it’s true for the organization at large.

Yet Rally, at its core, is still a project and program-management application. “We tend to stay above development tools,” Miller said. “We have 48 integrations across the development life cycle. We’re the layer on top that helps orchestrate the software process.”

So Rally sees its integration with Team Foundation Server as just another one of its integrations, providing the same functionality to Microsoft shops that it offers to shops of other types. “Our strategy,” Miller said, “has been to be somewhat neutral.”
#!
Dealing with disappointment
Joel Semeniuk, executive vice president of innovation at Telerik, agreed that agile uptake is reaching a maturity stage, but he also said he sees a “trough of disillusionment” that has been created by agile’s failure to live up to the hype. “We’re still seeing pockets of agile. It’s hard to scale agile sideways as well as up,” he said.

He also agreed with the manifesto’s directive that individuals and interactions are more important than tools. “Tools aren’t agile or non-agile. We use tools to become agile. Team Foundation Server allowed agile to grow” in the Microsoft ecosystem, he said. “It’s how the team used the tool” that made them agile, he added.

Telerik integrated its Team Pulse agile project-management tool with Team Foundation Server, allowing managers to track time against work done in TFS, Semeniuk said. Further, he said Telerik provides a feedback portal for users to make feature requests, vote on features or bug fixes, and provide feedback to back-end developers in near real time.

The company’s Icenium development environment empowers developers to create mobile applications using HTML5 and JavaScript. Although these are not traditionally seen as Microsoft developer skills, Semeniuk said “Microsoft shops are approaching mobile development from a non-Microsoft perspective. It’s part of the growing BYOD trend. Being able to write mobile apps using standards like HTML5 and JavaScript is extremely agile.”

Semeniuk went on to say that in Telerik’s customers, as well as in Microsoft, he’s seeing an embrace of agile. “Microsoft believes agile is the right way of doing things,” he said. And going forward, he expected to see a collapsing of DevOps into these agile processes. “Those [DevOps] teams are great agile teams.”

VersionOne’s CTO Ian Culling said this expansion into DevOps is part of the continuous-improvement mindset that agile organizations must have. “So many large enterprises are interested in agile at scale from the get-go,” he said. “They’re ready to pull the trigger on a significant transition, where in the IT group or even more broadly.”

But Culling said many organizations that have implemented so much open-source infrastructure around continuous integration, test automation and source control are struggling. “More progressive teams are moving away from the full single suite [of tools] to more of a best-of-breed approach,” he said. “Large enterprises that continue to try to push a single suite on their teams, that’ll erode pretty quickly. Agile wants to give people autonomy” over the tools they use, he said.

Agile without unit tests is just plain ‘reckless’
While card walls, user stories and continuous integration are pillars of agile development, so is test-driven development. While it can be a fairly difficult process to adopt, mature agile practitioners should be doing it, said VersionOne CTO Ian Culling.

“If you’re running iteratively, and you constantly deliver code on a story without testing, you’re running a deficit and building up technical debt,” he said. “Your delivery of stories will slow over time” as defects take longer to find and correct.

Eli Lopian, CEO of testing software company Typemock, took that thought a step further. Those not doing unit testing “are reckless agile practitioners,” he said. “They go for the speed but get caught at the end.”

The problem, he continued, is that “people are trying to become Olympic swimmers without being healthy.” While those teams see unit testing as slowing down the release cycle, he claimed just the opposite is true. “Code that has unit tests has fewer bugs, which reduces the QA effort,” which gets quality, working software out the door more quickly.

Microsoft offers unit-testing tools in Visual Studio, Lopian said, but he noted that Typemock integrates both with Visual Studio and Team Foundation Server to add features beyond those that Microsoft offers, and to provide a framework for unit testing that lowers barriers to becoming agile.

Typemock offers a visual-coverage tool so users can see which pieces of code are covered by unit tests and which aren’t, Lopian said. In the future, Typemock will offer one-button unit-test generation for code that currently isn’t covered by tests, he said. “Putting working software above all, putting communication above other things, that’s still how people are defining agile,” Lopian said.