• Prev
  • Next

Enterprise Agile: ‘Water – Agile – Fall’ Makes a Splash in New Forrester Report

Tony TimbolIt's safe to say that for Agile practitioners who are working with clients, the recent findings about enterprise Agile in Forrester's "The 2015 State of Agile Development Report” are not all that surprising. For Agile purists the findings may seem discouraging, but in my view, the report shows that Agile’s benefits are so clear, that it is driving change regardless of barriers to adoption.

This quote about enterprise teams struck me specifically, "The teams know how to integrate Agile development with waterfall practices in an overall enterprise governance framework. When done well, Forrester calls this Water-Agile-Fall. 'Done well' means upfront planning and an understanding of very high-level product requirements (water), then sprints kick off with further user stories of refinement, design, development, testing, and integration (Agile), and, lastly, release packaging and deployment (fall).”

The words "upfront planning" and "high-level product requirements" indicate that enterprises are trying to fit Agile into existing organizational lines of command-and-control, as opposed to decentralizing decision making. Change is hard - these types of allowances are expected.

This chart from the report underscores the challenges organizations are facing in full Agile adoption:

Forrester State of Agile 

What's the big takeaway here? Do not underestimate the challenge in moving from a functional line-of-business model to a product/value stream structure, which aligns better with Agile and lean software engineering. This transition brings many organizational, personnel, and financial issues to the forefront that are not so easily addressed.

Even as solid as the SAFe (Scaled Agile Framework) approach is to scaling Agile, enterprises should move deliberately and carefully and understand that scaling is less about technique and more about effective change management.

You can download a copy of the report here.


Tony Timbol
VP of Business Development & SAFe Program Consultant

 

Written by Tony Timbol at 05:00
Categories :

Agile Testing: User Acceptance Testing

TomUser Acceptance Testing (UAT) in an Agile project is generally more rigorous and timely than the classic end-of-project UAT found in waterfall projects. The classic definition of a User Acceptance Test (UAT) is a process that confirms that the output of a project meets the business needs and requirements. In waterfall projects, the UAT is usually the last step in the development process. The problem with that classic scenario is that significant defects are often found late in the process, or worse, the business discovers that what is being delivered isn’t exactly what they wanted. Agile projects provide a number of opportunities to interject UAT activities throughout the process, starting with the development of user stories, to the sprint reviews and demos, and finally the UAT sprints at the end of a release. Each level provides a platform for active learning and feedback from the business.

Agile UAT begins when user stories are defined. A user story should include both story and acceptance test cases (also known as acceptance criteria). As noted in Daily Process Thoughts, July 31, 2013, one technique for creating and grooming user stories is called the Three Amigos. This technique gathers a representative from the business, professional testing and development, so that all major constituencies are represented. As a story is defined, so are the acceptance criteria. Adding the focus on business acceptance criteria during the definition of user stories begins the UAT process, rather than waiting until later in the project. Laying out the acceptance criteria when you begin to work on a story helps the team to stay focused on what is actually needed and reduces the potential for rework and gold plating (adding extra features).

A second layer of UAT activity in Agile projects is found in the end of sprint demonstration. The Daily Process Thoughts, June 20, 2013, provided a description of typical demonstration (also known as a show ‘n’ tell or sprint review activities). As a reminder, demonstrations are planned so that the product owner and team can provide proof that they have solved the business need. Demonstrations are interactive, so that stakeholders can provide feedback and buy into the solution. Another technique that many Agile teams add to their working process is adding UAT tasks for each story. This ensures another level of user interaction as part of the development process, thereby increasing feedback and acceptance. In both cases, the interaction at the end of sprint is earlier than is common in waterfall projects.

The third level of UAT is the inclusion of a dedicated sprint to perform a final, overall user acceptance test. In this scenario, the units of work defined for the sprint would be focused on test cases or scenarios and then fixing any discovered defects. Having a sprint focused on UAT has risks. The risk is that delaying UAT until a specific sprint increases the probability of finding problems that require substantial rework later in the cycle, where they are more costly to fix. This is the same basic issue with the placement of the UAT in a waterfall project. So why do it? One of the reasons this approach might be needed is when users need to validate the entire system before acceptance (this happens in life critical systems and in many regulated markets). Developing stories with acceptance test cases, ensuring interaction with stakeholders at demos and adding UAT tasks in order for stories to be completed, will help minimize the need for a specific UAT sprint and mitigate most of the risks of this technique when you have to use it.

User Acceptance Testing is at least as rigorous in Agile projects as in most waterfall development techniques. As importantly, Agile UAT techniques are applied much earlier in the development process, providing earlier feedback to the team. Earlier feedback reduces rework by finding and fixing problems before they can get bigger. Many Agile UAT activities are part of the standard Agile practices, including acceptance test cases in user stories and generating interactions with stakeholders in demonstrations. When needed, extra activities are easily integrated into Agile development techniques, such as adding UAT tasks in developing stories or including UAT specific sprints. UAT activities build trust with stakeholders. UAT also proves to stakeholders that were not involved in the Agile development process that the project is delivering on the business needs. User Acceptance Testing is a necessary step in any project, Agile just spreads it out and does it earlier (and better).


Tom Cagley
Vice President of Consulting
Agile Practice Manager

Written by Tom Cagley at 08:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!