Agile transformation using JIRA / Confluence

Introduction    

Starting off on an agile journey is a multi-faceted transformation. A lot of times it is IT led with business divisions being pulled along for the ride. This is the case since the IT organizations have a PMO with the project and program management competencies in it. The biggest change in organizations moving to Agile is to get traditional managers to change their mindset.

When agile first started to emerge in enterprise IT shops, small self-organizing teams of highly skilled developers would deliver projects faster in short 2 to 4-week development cycles rather large teams working in long drawn out waterfall cycles. These teams would use techniques such as pair programming, delivering small working pieces of functionality frequently and not going in for extensive documentation. Such techniques have now become best practices in Agile.

In the earlier days of Agile there were no tools like JIRA or confluence. Stories and tasks would be tracked on white boards using stickies and burn down chart would be created using spreadsheets (I think they were prettier than JIRA ones though).

One of the assumptions that is made while starting on the agile journey is that one is managing skilled individuals working together as a high performing self-governing team. However, what often happens is that a new team is put together and one has to morph the group into a high performing, self-governing team of skilled developers. The blog below describes my view of how this can be achieved in a three phased manner and is based on my experience over several projects and organizations.

Before starting the phased approach

Before starting on the phased approach to Agile Scrum transformation, it would help to have several issues ironed out as described below.

Identify the product owner – Often times organizations starting Agile are not willing to commit a full-time product owner to be a part of the team. This problem arises specially on the business side when they work with IT teams. The product owner is then either part time, is supporting multiple projects and does the product owner role in his “spare time”.

It would help to have the environments and tooling in place such as

  • Continuous Integration / Continuous Deployment or Delivery (CI/CD) – I have found that even simple things like build time needs to be cut down to enable agility. In one of my previous roles, I put a team of architects together to cut down on a build process that took several hours down to 2 hours so that we could run CI/CD every two hours.
  • Automated Testing – I have found that it helps to use tools like selenium to automate UI / UX testing as well as unit testing server side components using xUnits.
  • Test Driven Development – I have changed development processes to enable test driven development to start by putting in the tooling and enabling developers and testers to engage with the customer to build out test cases and code xUnits as the first step of the development process
  • Virtualization / Cloud orchestration – Typically use docker, vagrant and other tools to standup environments on demand.

Also, it would help to identify all sprint dependencies before embarking on an Agile transformation journey. These dependencies could be at the enterprise level, such as impedance mismatch with sprint execution and finance and budgeting process or HR issues relating to career tracks for people participating in the sprint process. e.g. What happens to people who were working in the waterfall methodology as a business analyst? Are they going to be called a product owner now and get a raise? What about a project manager? Do they become scrum masters? What would their career tracks be? (decisions or tasks / activities) before the sprint starts so that one is not waiting on them during the sprint.

Risk mitigation should also be addressed prior to getting into sprints so any plan can be executed during the sprint. Risk planning and mitigation should be an ongoing process and should be included in the sprint ceremonies.

All phases do not have to flow sequentially, but activities from each phase can be implemented in earlier or later phases as needed or may not be implemented at all.

Phased approach to Agile Transformation

Three phased approach to transformation is broken into three broad areas below for each phase.

  • Process
  • Tooling
  • People

 


 

  1. Step 1 – Micro Managed Waterfall Stage
    1. Process – Define the development process and start implementation – Demand Push – Task / Demand assignment. Start the ceremonies – start with some – Daily Scrum
    2. Tooling – Put minimum tooling in place – JIRA / Confluence, virtualized environments
    3. People – Team in forming stage
  2. Step 2 – Hybrid Stage
    1. Process – Implement the development process – Enforce discipline. Mature the ceremonies – add retrospectives
    2. People – Add additional tooling – CI / CD e.g. Jenkins, environments on demand
    3. Tooling – Team in Storming and Norming
  3. Step 3 – Mature Scrum
    1. Process – Disciplined team – follows the defined development process. Perform all ceremonies correctly such as sprint grooming.
    2. Tooling – Complete tooling – automated testing for UI / UX
    3. People – Team in Performing stage

Agile Scrum Activities in each phase

These activities are bucketed in each phase below and are based on my experience. They can be moved around and prioritized in a phase as needed. The should be used mainly as a check list. Performing these activities will raise the agile scrum maturity of the organization.

Phase 1 – Micro Managed Waterfall Stage

  • The development process can be defined in the JIRA Kanban board in the standard format of “To Do”, “In progress” and “Completed” lanes. Create a list of standard subtasks as shown below. These subtasks can be created at the start of the sprint in the “To Do” column for each story and moved to “In Progress” and “Completed” as work progresses. However, it is important to enforce developer discipline so that tasks are moved as the corresponding activity is completed. Sample development subtasks for each story could be as follows –
    • Analysis
    • Development
    • Unit testing
    • Deploy to Test box
    • Tester Review
    • Raise Pull Request (assuming Github is used for source code control)
    • Pull Request Review (assuming Github is used for source code control)
    • Code Merge to DEV Branch
    • Code Move from DEV to QA
    • QA Verification

    Some tasks above are what I would call “tracking tasks” to indicate the status of the story and could have no time or a little value of original estimate. Other tasks should have the planned effort put into the original estimate field in JIRA when tasks are created. The tasks should be created in the order of the process activities in the “To Do” column, which would help to indicate the correct status of the story.

     

    If process is not well defined, and process changes takes during project execution, it will be difficult to determine sprint velocity. e.g. if completing code and unit testing was considered done and stories were closed before QA validation was completed, then measured sprint sprint velocity will fall once QA validation is made mandatory, before recovering.

  • For sub tasks –
    • Break up stories into sub tasks as much as possible of about 4 – 8 hours in duration at the start of the sprint.
    • Create standard sub tasks as above with original estimates (for tracking subtasks original estimates can be put as some small value)
  • Remove levels between final customer, product owner and development team members. This will allow developers to get a better understanding of the requirements and reduce defects.
  • Remove dependencies and break up big stories (i.e. with large story points) into smaller stories.
  • Integrate JIRA and confluence
  • Use shadow product owner to work with offshore team and customer
  • Track utilization – Micromanage demand and allocate work instead of individual developers managing capacity and pulling demand. This can be done in JIRA using the “Original Estimate”, “Remaining Estimate” and “Time Spent” fields that can be retrieved using JQL (JIRA Query Language). For this to work developers have to log their hours in JIRA against story sub tasks.
  • Allow for management activity overhead like tracking utilization, resource smoothening, resource leveling and reallocating work. If there is not enough time for demand planning in two short two-week sprints, consider longer 3-week sprints. As the team matures, this activity can be eliminated and sprint size reduced to two weeks.
  • For Ad hoc tasks not associated with any story but required in a sprint use a zero-point story to give visibility instead of creating a new Kanban board.
  • Manage team size. If team becomes too large go in for a scrum of scrums approach.
  • Get developers to commit. Once load is managed correctly and developers pull demand, it will be easier to commit and prevent stories from spilling over from sprint to sprint.
  • Give proper duration for ceremonies e.g. in sprint planning so that all stories can be estimated through proper story point sizing and with the right people in the room. Don’t have managers or developers not involved in the development work provide story estimates.

Phase 2 – Hybrid Stage

  • Don’t pull large story points into sprints. and remove dependencies before pulling into sprint
  • Release planning – Define the process integrating QA, UAT and staging deployments
  • Sprint grooming or preplanning – As multiple future sprints are planned out in the JIRA board and backlog grows large resize stories and remove duplicates. Not all developers need to participate in these sessions. This would reduce sprint planning time with the larger team.
  • Have well defined exit criteria

 Phase 3 – Mature Scrum

  • Integrating HP ALM to JIRA
  • Developers self-managing demand i.e. pulling demand and committing to deliver stories
  • Code quality checks – static / dynamic analysis
  • Code coverage
  • Automated functional and non-functional tests

Scaled Agile

Once Agile Scrum is purring along smoothly it is time to scale the agile process for which several frameworks are available such as SAFE, LESS and DAD

Best practices for JIRA / Confluence Tools

  • Reporting
    • Burn down chart in confluence
    • Using “Original Estimates”, “Remaining Estimate” and “Time spent” to perform demand and capacity planning, track utilization and work allocation for developers. Developers should put in “Original Estimate” for task during creation and log hours as a task, progresses.
      • Avoid single threading resource issues
      • Avoid overloading resources – resource smoothing and leveling
      • Manage capacity for leads for release planning and coaching developers
      • By logging hours as a task progresses % completion can be tracked
    • Report of subtasks “In Progress”, “To Do” and completed per developer in JIRA can be generated in confluence to show how work is progressing
    • Report for sub task creation vs resolution for a sprint gives a view of the progress
  • Documentation – Linking requirements documentation in Confluence to JIRA stories and subtasks

 

This blog contains my personal views and experiences

©Partho Sandell

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s