Agile Buddha - Page 9 of 23 - Demystifying Agile, Getting to its Core

Jira and Agile : Using One Backend for Multiple Platforms

It’s common to have applications available for multiple platforms (web, Android and iOS) these days. In most cases, common backend services are used irrespective of the interface.

In such cases, it is tempting to have separate teams for backend and front-end interfaces. Unfortunately temptation in this case doesn’t help the business. It becomes very difficult to see the functional progress while having separate backend and frontend teams. On the surface, it looks like everyone is busy but in reality, the outcome can be frustrating with no production ready features.

The solution is to have functional cross-functional teams which could work on a vertical slice end-to-end. For instance, it’s ideal to have a team focused on iOS platform comprising both iOS and backend developers.

Makes sense, but then how to handle the redundancies as the same service may be useful for web as well?

Streamline Your UAT and DevOps – Kanban Boards

by Avienaash Shiralige 4 Comments

In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.

Note: People landing on this post directly, please read earlier post to get context of the problem.

This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.

Use Planning Board for Product Backlog Grooming

by Avienaash Shiralige 4 Comments

In our earlier post – Improve sprint throughput we had discussed about how important it is to have stories ready for play before team picks it as part of the sprint. In short, if half-cooked stories are pushed to sprints for execution, then team will spend lot of time analysing, re-working and this eventually reduces team throughput. To address this challenge, few of my teams thought of creating a separate planning board in Jira to track planning readiness. This board was used by PO primarily to keep a tab on the backlog and also by team members during backlog grooming session.

Team was using Atlasssian Jira, I will show here how we modified the workflow and boards within Jira. Some of the issues teams had faced with the backlog not being ready were:

Insufficient scenario analysis in user stories
Lack of functional and technical impact analysis
Not much details/mocks within the story
Team doing sizing estimate during sprint planning – this was the first time team was seeing those stories and hence made sprint planning long and inefficient

Hence a workflow was designed to address above issues. Take a look at the workflow below(pasting it from Jira).

#noprojects with Cross Functional Feature Teams

by ShriKant Vashishtha 1 Comment

whatwedo-teambased-crossfunctional-small

Sometimes #noprojects (deliver continuous change successfully without using a project) approach alone may not be enough for a software product. This is especially true for large enterprises where any valid business outcome requires close interactions of multiple software products.

In such cases, problem is how to resolve dependencies among software products. First approach which is also very common, is to agree upon a software interfacing contracts between software products. Each individual team then work in isolation while keeping other team’s software contract in mind. When done, teams integrate pieces together.
[Read more…] about #noprojects with Cross Functional Feature Teams

The GQM Approach: A Framework for Defining and Measuring Effective Software Metrics

by ShriKant Vashishtha 4 Comments

Software metrics are important, as they tell you the transparent truth of software delivery. The question remains – which metrics should I use, and why?

Sometimes people just look for an available or known set of metrics and then add more as and when they discover anything new. But does it really make sense to try and apply those known metrics to any scenario?