At Scrumday 2017 held in Simcorp I presented parts of the work that I have been involved in and the thoughts that follows an agile transformation.

On a personal level – the journey with Bankdata already started back at Scrumday 2016 where my colleague Claus gave a talk on the agile transformation called b-agile. This made me jump ship and join Bankdata later the same year.

I joined an organization under change going from traditional waterfall and plan-driven development into agile and Scrum development.

It has been almost 6 months since I joined as an agile coach. The time has passed by fast and has given me opportunities and successes with the teams.

What have we have achieved at Bankdata?

Bankdata and the b-agile transformation completed by the end of 2016. During the transformation we have achieved:

• We focus on going from doing agile into being agile
  The mechanical parts of Scrum are up and running and the focus is now on being agile and having an agile mindset
• We have real customers as product owners
  Our product owners are employees hired at our customers. They sit with us physically on our location on a daily basis and participate in all events
• We have buy-in from management
  They support the transformation and understand what it means to have an agile mindset – in fact many of them are working in management teams doing Scrum to plan their work
• We have many agile coaches
  To facilitate the continuous improvement we have locally anchored agile coaches that are empowered
• We have introduced technical coaches
  Supporting the agile coaches and helping to enforce strong software craftman ship

 

A group of 15 internal and external agile coaches led the transformation. In the process, a 50 year old organization was transformed covering more than 650 employees in 100 teams. It was celebrated by eating 690 pcs of the Danish cake “flødebolle”.

The b-agile transformation was a “standard” Scrum roll out with a high organizational impact. We started by training the development teams, Scrum Masters and Procuct Owners using industry standard courses. Once a team had been trained an agile coach – either central or local – was assigned to follow the process implementation and improvement.  Together with the agile coach, each team performs continuous improvement  – but the big question came up: How do we keep up the global continuous improvement on organizational level.

This led to the question: What happens after Scrum?

We have seen so many organizations implementing Scrum and failing at keeping focus on the continuous improvement. Once the b-agile transformation commenced at the end of 2016 the agile coaches was looking for answers to what would be the logical next step. Initially we did a brainstorm in the agile coach guild, coming up with ideas of what could come next. But was this the right list of ideas?

Crowd storming

Agile as we are, we decided to scrap our own list and instead invite all employees and managers to join a crowd storming campaign. Crowd storming is a decentralized collaborative brainstorm. We hung up posters on all our locations and invited everyone to hang post-its with their best ideas. This was a great help. Many of the inputs were not on the initial list, but key to improving agility in the organizations.

Some of the ideas generated were:

• Frequent deployment
  Working in sprints means that we need our platform to support shorter release cycles for production deployment
• Automated test suites
  To enable frequent deployment we need to assert quality at a higher speed with less manual testing
• Scaling Agile
  We have had a focus on single team responsibility and optimization but saw a rapid demand for frameworks and processes to aid work across several teams
• End-User Feedback
  Even though we have customers as Product Owners we were still lacking direct end-user feedback on releases
• Agile Management
  With a strong focus on teams and little focus on management, a demand for training and definition of agile management was identified
• Cross Functional Teams
  We all know that the team must possess competencies that suites the Product Backlog, but how do we actually do this?

All ideas submitted through the crowd storming campaign was collected and aggregated and ranked in three tracks shaping b-agile 2017:

• Business
  Covering anything relating to customer collaboration and business interaction
• Transformation
  Covering anything relating to processes and management
• Technical
  Covering anything relating to software development and tools

Technical Coach

Looking into the competencies needed for b-agile 2017 we had a clear picture of missing competencies within the agile coach guild. We saw that the majority of agile coaches came with a project manager, business developer or processes consultant background – making them obvious to support the business and transformation tracks. However, only few of our agile coaches had a technical background as software developer or architects.

To close the competency gap we introduced a new role called technical coach.

Our expectations to the technical coaches were:

• Software Craftsmanship
  Striving to be better and more professional software developers
• Design patterns
  Knowing how to design for the future using well known design patterns
• Refactoring and incremental design
  Knowing how to write code enabling frequent deployment and agile delivery
• Test principles and practices
  Knowing how to test in an agile context
• Domain knowledge
  Having knowledge of domain, systems and development tools

On top, the technical coach needs to team up with an agile coach to do:

• Coaching
• Teaching
• Facilitation

In junction, the agile coach and technical coach guilds possess the competencies needed to implement the three tracks of b-agile 2017.

In the following I will exemplify what we have been working on so far – starting with agile testing from the technical track.

“Let’s move away from software crap to software craft!”

The statement is on the edge; I am sure that we did excellent software before but how can we be sure? We need to work with quality assurance and agile testing in order to improve our professionalism and enforce software craftsmanship.

To assist the teams we designed a roll out with of 4 elements:

1. AS-IS
   Define and agree on current situation, portfolio test strategy and risks
2. Training
   Common theoretical understanding of agile testing
3. TO-BE
   Plan and prepare future situation through test vision and actions
4. Coaching (Technical coach)
   Coaching on tooling, methodology and software craftsmanship

Together with the agile coaches, our technical coaches are responsible for implementing this and keeping the continuous improvement in place afterwards.

Charlie Brown Model for agile testing

One of the tools that we provide our teams with is the Charlie Brown Model for agile testing. The aim of the model is to embed quality assurance inside a sprint as an ongoing activity. Further, we saw a demand for something that was easy to learn and bring back to the teams. Taking the model, a team can easily plan tasks during refinement or sprint planning.

The elements of the Charlie Brown Model are:

• Story kickoff
  Team learn about the needs and demands behind the story
• Mind map
  Analysing the story and how quality can be assured in terms of the functionality that needs to be developed
• Test design
  Choosing how and what to test in the sprint
• Test
  Executing on the planned test as early as possible

Other activities such as code design, architecture and development is executed in parallel. The model only illustrate quality assurance work.

“Customers work with process optimization; we work with product and system development”

Another example from b-agile 2017 is found in the transformation track where we looked into scaling agile and handling cross team work.

We have identified an impediment in our setup. We have organized our Scrum teams around a single software product or system, while our customers – that are banks – are thinking in processes and customer journeys. This means that when our customers have an idea for an end-to-end process optimization they need to target several individual Scrum teams with chunks of the final solutions. This is not ideal.

Trying to solve this, we looked outside Bankdata to seek inspiration and found the following conclusions:

• Scrum Guide
  No help here, describes that “implementations may vary depending on context”
• Scaled Agile Framework (SAFe)
  Big and massive blue print for implementing scaled agile; our organization is not suited for the governance hinted in the setup
• Spotify
  Looking into tribes, guilds and chapters we did not find a perfect match; it seems to focus on knowledge sharing and not solution development
• Nexus
  We found that the Nexus Integration Team was the closest match available and grew our own model on top of it
• Bankdata History
  Customer demands going cross organization is as old as the company and we have many previous successes that we need to incorporate

 

FA-PO-ITA: Makes people talk

Our instance of the Nexus Integration Team is called FA-PO-ITA and is made up of the Danish abbreviation of the needed competencies:

• FA: Business architecture competencies
• PO: Product Owner competencies
• ITA: IT architecture competencies

FA-PO-ITA comes in two flavors:

1. Continuous team
   Permanent team with a business architect and an IT architect handles incoming requests that does not belong naturally to any Product Backlog. To solve the task the relevant development teams and their Product Owner is invited to a discussion about priorities and coordination.
2. On demand team
   Dynamic team that grows and shrinks over time. When a Product Backlog Item requires work conducted by other teams an instance of FA-PO-ITA is created. The involved Product Owners meet with relevant team members covering the competencies of business and IT architecture.

To separate the responsibilities between FA-PO-ITA, individual Product Owners and Development Teams we have created a simple flow:

• FA-PO-ITA
  Responsible for describing needs and benefits and to gain priority across Product Backlogs
• Individual Product Owners
  Responsible for prioritizing according to agreed deadlines with FA-PO-ITA
• Development Teams
  Responsible for story point estimation, refinement, coordination and development

“Major decisions should be made by the involved people with the right knowledge”

The final sample that I have chosen is team forming from the transformation track. We strive to have stable teams, however in some cases we need to adjust teams and set them off to a great start.

A consequence of the agile management discipline is to decentralize decisions to the involved employees. This is manifested in our organization when forming new teams:

• Product Owners outline vision and purpose for new Product Backlogs
• Managers outline the framework of empowerment, e.g. physical location of the new teams
• Employees decide which team they belong
  • Either by voting with their feet
  • Hidden vote by e-mail
• Team forming is facilitated by Scrum Masters through team building and other relevant activities

Summary

To sum up, b-agile 2017 is a bottom-up initiative with great support from management. We work on improving agility in terms of three tracks: transformation, business and technical – and that is what happens after Scrum in Bankdata!