Revisiting Workflow to Increase Velocity

BY ALI HROMIS // August 10TH 2016


In the last entry, I introduced concepts of scaled agile and discussed how SAFe principles are applied to our current project. I also frequently reiterate the need to look at agile practices through the lens of your particular company, culture, and objectives. This sprint, our team was challenged to cope with aspects of the project that don’t align to common best practices, but were necessary given the nuances of our situation.

Since the beginning of the project, both development teams have shared a Product Owner. While each team had a dedicated Business Analyst (BA) to support the Product Owner, she was still faced with several challenging tasks: review stories produced by two BAs, ensure that both new lines of business are consistent with each other and previously developed lines, conduct User Acceptance Testing (UAT), provide current sprint clarifications…the list goes on.

It became apparent that responsibilities needed to shift and that workflow needed to be addressed.  We needed a way to rapidly produce high-quality, consistent, and complete stories without overloading the Product Owner. The combined skillset of the BAs is rooted firmly in Software Development Lifecycle (SDLC) and a strong understanding of this particular business domain, so their responsibility grew to support a productive development and Product Owner team.

This led us to creating a well-oiled, user-story-authoring and review machine, involving both BAs as authors and the Product Owner as the ultimate approver. The review cycle ensures quality Acceptance Criteria are included within each user story, specifically evaluating testability and completeness. We also pay close attention to consistency between lines of business and throughout the application itself. We verify in verbal conversation and demoes that the words contained within the Acceptance Criteria are understood by both BAs in the exact same way, and that the development, testing, and Product Ownership teams will have that same understanding.

After adequate review and update cycles have been completed, the story is then ready for estimation. We indicate when stories are ready for estimation to support the productivity of our estimation sessions. The review process allows for the major details to be addressed, while minor details can be confirmed in estimation with the Product Owner. The final step is for the Product Owner to officially approve each user story, which must be accomplished before we can commit to delivering it in Sprint Planning.

The result of this workflow change is still too early to be measured, but it has definitely led to improvements in consistency and testability. The development teams and testing teams are much more aligned, and have noted clearer expectations mid-sprint. The UAT team is able and empowered to assess defects versus enhancements, and is learning more about SDLC concepts that their decisions impact. While more improvements are inevitable, the progress to date has supported a more agile (but better prepared) high-performing team.


Scaled Agile



In the first update, I introduced the project as two teams sprinting in tandem. Since then, we’ve learned a thing or two about how to scale the agile framework and mindset. One challenging element of any agile project is that there is no single “right way” to adopt it; the team must be able to learn from their unique experiences to create a high-performing development team. Such is the expectation with multiple teams, there are simply more team members’ perspectives to consider.

One of the ways to consider scaling agile is through the Scaled Agile Framework known as SAFe. Again in this framework we see the encouragement to adjust the framework to fit the enterprise architecture of the team’s organization. Several of the SAFe Principles apply to our project, and can serve as guidance as we continue to adjust our processes.

A few of the impactful principles are highlighted below.  We will dig into more in future posts.

#1 // Take an Economic View

This principle supports ensuring the building team is always making decisions in the right economic context. The team must understand how to weigh risks, costs, and benefits associated with development and operational decisions.

By embedding Business Analysts (BAs) on each team, we have the ability to understand the ‘Why’ of what we’re building. We are building more than a system; we are building a competitive advantage in the marketplace. Both teams must fundamentally understand and support that concept in order to deliver on the business value required to make the project economical.

#4 // Build Incrementally with Fast, Integrated Learning Cycles

This concept appears over and over (and over and over) again in agile frameworks. However, we’ve had to learn to apply this to a scaled team. We’ve implemented two key changes that have led to significant communication improvements and improved team dynamic:

We created a core team consisting of key members on each team including the Scrum Master, Product Owner, Business Analysts, and Architects. It allows us to share key learnings and retro outcomes across project teams without impacting development velocity with increased team meeting times. The members from each team then share the Core team learnings with the respective teams, but decentralizing the communication allows for better dissemination of important information.

We combined sprint planning meetings to ensure shared responsibilities were appropriately accounted for on each team. This integration again supports effective communication, but it also allows team members to feel more ownership over respective areas of the application. By giving the team members a holistic view of the project, they have been more apt to lead large development efforts of key aspects of the application.

In conclusion, scaled agile has different considerations than a single agile team. The importance and complexity of considering each individual team member also scales with the size of the team. Be creative, be adaptive, and be flexible to ensure improvement and success.

Realizing the Full Potential of Agile Through Automated Processes

BY ALI HROMIS // June 6TH 2016

As we near the end of Sprint 4, we reflect on core learnings and celebrate the obstacles we’ve overcome. We have identified merge conflicts, broken builds, and process failures that have led to interrupted progress, unplanned work, and overall frustration in each sprint. It was time to fix it!

The Agile Manifesto is supported by 12 guiding principles, the first of which is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Other principles highlight working software as the primary indicator of success and the importance of delivering that software frequently. The sheer number of build-test-deploy cycles required to deliver on these Agile principles increases the pressure to have these core processes in a rock solid state.

TFS Metrics Screen CAp

This Sprint Review, we will be celebrating 2 significant wins.

  1. We established automated build and release processes with visible quality metrics. Our architect, Kyle Burns, led the charge on this one. He analyzed the root cause of the build and release related productivity-killers, and put several system-enforced policies in place. The policies support unit test code coverage and strategically placed technical gateways in the hopes of keeping the development pace uninterrupted. We now publish metrics with each release in our shared team site, allowing us to maintain visibility of good development practices. The solid process and visibility into meaningful metrics help the business gain confidence in the stability of the product.
  2. We started building our automated test suite. Our Quality and Validation lead, Jeremy Johnson, has been reminding the team of the many benefits that come with automated testing since we started the project. To maintain a high quality product, rapid development of workable code must be coupled with rapid testing of that code. It supports the agility of the team and reduces time lost due to human error and recurring bugs. Though we’ll need some time to catch up on previous sprints’ test, this sprint we took the first steps toward a fully automated suite.

Making the decision to automate these processes can be daunting, but it doesn’t all have to be done at once. It can be approached iteratively and improved over time, similar to the app itself.

Sprint Two Wrap-Up: The Value of Retro

BY ALI HROMIS // MAY 18th 2016

A key concept of Agile Scrum development is the ability to reflect on work habits, methodologies, and philosophies employed through sprint Retrospective (Retro, for short). In Retro, each sprint team member voices what they believed worked well, what didn’t work well, and suggestions for improvement in the coming sprints. It is meant to help identify ways to increase team velocity, decrease productivity blockers, and lead to a more efficient team as a whole.

The value of Retro extends throughout the lifecycle of an Agile project; however, it has siginificant importance during the team’s forming and norming stages. As our team continues to understand the best ways to work together, having a formalized time to openly communicate concerns and areas for improvement is imperative to healthy growth. During our last Retrospective, we focused on a common Retro technique in identifying things to STOP, START, and CONTINUE. Here are some of my favorites from Sprint 2:


  • Standardizing the pull request review process to ensure the appropriate quality checks are in place before merging code, even if it’s “just a small change”
  • Early communication of testing approach to ensure testers have the necessary test tools and developers are producing testable code


  • Exclusively committing to large stories that are difficult to move through the SDLC process (dev->QA->UAT)
  • Developing against current model when a future model will soon be implemented


  • Creating testable and clear Acceptance Criteria
  • Team focus on team In other words, continue to help each other reach commitments as a team whole versus viewing stories as the responsibility of only one team member.

These items are recorded electronically by the Scrum Master but our team also posts them visibly in our Agile Team Room. They serve as a constant reminder of the best way to approach specific tasks and prevent us from making the same mistakes twice. On the other hand, they remind us of the positive habits we’ve formed. As important as it is to mitigate negative habits, it’s equally important to celebrate the accomplishments and decisions that contributed to a successful sprint.

Sprint One Complete!

BY ALI HROMIS // May 2nd 2016


We’ve just finished Sprint 1! Sprint 1 was full of learnings, and we expect the next few sprints to be similar. On the Product Ownership side, we worked to improve the size of our user stories to better support fluid development. While granularity is necessary to ensure work is moved through the process, coupling related features at the appropriate times can increase the velocity of individuals and the team as a whole.

On the development side, we’ve started to build the system. The system shares a landing page with other lines of business in separate solutions, so we’ve begun with implementing the first data entry page of the risk rating process. The developers are quickly ramping up on the differences between AngularJS and AngularJS 2, specifically on the differences in syntax and backend binding patterns. We’re pair programming, conducting collaborative reviews of the UI and the code, and sharing design and implementation approaches to ensure the team learns all key aspects of the app.


Agile Journey: Introduction

By Ali Hromis // April 20th 2016

Pictured from left to right: Matt LaPaglia, Kyle Burns, Johnny Bretz, Ali Hromis, Teddy Sterne, Jeremy Johnson, Christopher Pratt

It’s a recurring event: A project gets delayed by the constant yet inevitable (and often justified) change in requirements. Or, how about an unsettled stakeholder frustrated with the lack of transparency into project progress? A project plan completely upended because of an unforeseen technical hurdle? Employing the Agile Development Methodology addresses these concerns head-on, relying on concepts of flexibility, incremental progress, and customer satisfaction as guiding principles to software development.

Nautilus Insurance engaged Allegient as an extension of their in-house development team. Our team is providing the additional velocity the Nautilus team needs to deliver two tightly-integrated, custom, line-of-business modules within a single application. While their current team readily employed the necessary skillset to deliver both lines, our team offers the ability to deliver both lines of business within 2016.

The Allegient team consists of 5 Developers, 1 Validation/Test Lead, and 1 Business Analyst. We share 2 team members, the Scrum Master and Product Owner, with the Nautilus team developing in tandem with us. Our developers are highly skilled in ASP.NET Core, Typescript, and AngularJS 2, among other technologies. Our Validation Lead is passionate about automated, repeatable tests that increase the velocity of the team and the quality of the product. The Business Analyst focuses on making the lives of the Scrum Master and Product Owner easier, understanding Nautilus culture, goals, and concerns to support the needs of the development team when competing priorities undoubtedly arise.

In this series, we hope to bring you an insider’s perspective of project progress through the eyes of the agile team members. We’ll visit topics regarding the above technologies, the progress of the project, and agile best-practices to give you a play-by-play of what an agile project life cycle looks like in full-swing.

Stay tuned to this space in the coming weeks for regular updates so that you can follow along in real-time the progress of an Agile engagement like only Allegient can provide.