Rugby Scrum

The original idea of Scrum came from a 1986 HBR article “The New New Product Development Game“, written by Hirotaka Takeuchi and Ikujiro Nonaka. The teams at Toyota and elsewhere reminded Takeuchi and Nonaka of the game of rugby and they called this style of project management “Scrum,” a short form of the term “scrummage” where the game is restarted when the ball has gone out of play.

So what’s so significant about Scrum? Why do we call it Scrum and not Cricket, Swimming or some other game?

It’s just because in rugby Scrum, the ball gets passed within the team as it moves as a unit up the field. Scrum is all about everyone doing everything all the time. It’s an important point to remember as otherwise Scrum becomes yet another framework with 4 ceremonies, 3 roles and 3 artefacts.

The foundation of Scrum encourage one-piece continuous flow. So in a daily Scrum, instead of answering 3 daily Scrum questions, team looks at the Scrum board and plans on how to swarm to finish the top story on the board.

It may happen, depending upon the tasks identified for a story, 3-4 people decide to swarm and finish it. And then the rest of the team picks the next story. Daily Scrum is a sprint planning in small. You replan the sprint every day.

If team is working like this, there should be maximum 2-3 stories (depending upon size) in progress at any point of time, depending upon the size of the story.

So you see, if team decides to swarm, one doesn’t require WIP limits anymore. The team focuses on finishing existing ones before picking anything new.

As we discussed the key idea of swarming here, it’s important to understand that the idea of every team member picking one individual story to work on doesn’t really work. It blocks the delivery pipeline as any story a tester may work on comes after a week or so.

At that point of time, a tester may get multiple stories to test and may become bottleneck as there may be too many things to work on. That kind of scenario is not the ideal state of flow but is more like a Scrumfall in which work arrives in a batch after a period of time.

References

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ 0 comments }


I spent a big amount of my IT journey in working with IT Service organizations which Product organizations call as vendors.

While product organizations can decide how exactly they would want to work, teams from service organizations are mere extension from a customer enterprise IT strategy standpoint. Whether to work in Agile or not, Agile or AgileBut, all that is driven by the customer. If customer continues to work in Waterfall, you may not use Agile in isolation.

For service organizations, money comes from the headcount and the billing rate. As long as that’s improving while keeping the status quo, sometimes management may not see any specific value add in focusing on things which are not burning. That includes innovation, adopting Agile, TDD or focus on long term quality.

In short, customer drives the show. If customer is quality conscious, vendor follows the suit. Otherwise maybe not.

Service organizations play the software development service provider role in the enterprise development value stream. They focus on optimizing what they essentially work upon from Agile and DevOps standpoint which translates to improvising technical practices, automation and some DevOps technical practices.

While doing so, the trouble is – they don’t get the awareness of the whole, the whole enterprise landscape. That perspective is important for enterprises implicitly but not necessarily out of question for service organizations. It’s not easy to get such awareness. That’s the reason it becomes easy to miss.

In some Indian Agile conferences, where audience are majorly from service organizations, sometimes, people find anything beyond their technical scope as less useful. There, it seems like, automation and DevOps technical practices are the panacea of software development world. These practices are easy to talk about, difficult to implement and are definitely not the low hanging fruit for any enterprise.

There may be many other low hanging fruits which bring a lot of value add and reduces the cycle time without spending a lot of time, money and resources.

I understand the dilemma, however without understanding the whole or the big elephant, it becomes difficult to provide the real value add to the customer.

Good people in such orgs who really want to work in Agile environment find themselves helpless unless that’s the part of customer IT strategy. Employees may then get frustrated because of lack of opportunities.

What if service organizations are ahead of the curve and help customers in looking ahead? That requires spending on innovation and research which not many orgs do as of now. But you see, the focus on innovation has become important for survival these days.

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }


There have been a lot of agile success stories but mostly are around project challenges and how teams overcame them. In those high level details, the experiences from the trenches get hidden or get overlooked.

There are still many projects and people, who are transitioning from waterfall to Agile. It’s interesting for such people to hear the experiences from similar people (who moved waterfall to Agile) around their role, i.e. how for a developer role things got changed and similarly for tester/BA/Scrum Master roles as well.

This post is based on the real interviews of team members of such a project in a large enterprise. The team members shared their perspectives around their role. For everyone in the team, this was their first ever Agile project.

Hurry and Read the rest of this post!

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

No Standup remote collaboration

What happens when each team-member of your team works from a remote location (possibly from a different time-zone and country).

How do you sync-up in such a team?

Hurry and Read the rest of this post!

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

Organisations are embracing DevOps which is great. However the whole adoption is causing a lot of confusion as well.

Some of you might have heard the term “Agile and DevOps”. With that it looks like Agile and DevOps are different. To over-simplify further people assume Agile is all about processes (like Scrum and Kanban) and DevOps is all about technical practices like CI, CD, Test Automation and Infrastructure Automation.

This is causing a lot of harm as some organizations now have Agile and DevOps as two separate streams as part of their enterprise Agile transformation. Agile by definitions disrupts silos and you see, in this case people are creating new silos in the name of Agile and DevOps.

With that background in mind, let’s try to understand what exactly DevOps is all about.
Hurry and Read the rest of this post!

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

In one of our earlier posts I discussed the elements and benefits of “Definition of Ready”. However it’s quite common to see totally opposite views of purists as they believe that Definition of Ready is not required at all.

quote-lack-of-clarity-is-the-number-one-time-waster-always-be-asking-what-am-i-trying-to-do-brian-tracy-121-38-84

I agree to their views to some extent if it’s all about collocated teams supported by dedicated product owner in the same time zone.

However, distributed Agile is a different beast altogether. It’s quite common in India to work with customers in opposite time-zones. Distributed communication essentially is an overhead. So the clarification which you receive in minutes face-to-face with collocated product-owner may require multiple iterations of distributed communication. Multiple iterations essentially mean multiple days.

So a READY user-story which could be finished in 2 hours now takes days to complete because of to and fro communication between distributed team-members to resolve unresolved queries.

Definition of Ready in such cases helps in bringing clarity and in keeping team members and product owner on the same page. Any absence of clarity essentially complicates the cycle time and throughput of a sprint.

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

Multiple Platform application development
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?

Hurry and Read the rest of this post!

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

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.

Scrum Board

 

Hurry and Read the rest of this post!

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

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).

Planning Board in Jira

Hurry and Read the rest of this post!

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

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.
Hurry and Read the rest of this post!

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ Comments on this entry are closed }

Which Software Metrics and Why? Introducing Basili’s GQM Approach

by ShriKant Vashishtha June 16, 2016

With my last post, it is evident that 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 […]

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
3 comments Hurry up and read the full article →

Why do We Need Software Metrics?

by ShriKant Vashishtha June 4, 2016

Humans mostly have a tendency to go by their gut feeling. At the same time, machines mostly don’t tell a lie as their only job is to emit the necessary information. That’s the reason people like me are scared of weighing machine as that could break the myth of my handsomeness 🙂 . Your family […]

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
3 comments Hurry up and read the full article →

Mind the gap: Engineering Teams in 21st century, Management in 20th century

by Avienaash Shiralige May 12, 2016

Quite often I get to see engineering teams – upto middle management being new to agile, are ready to give it a try. But they have real problem on hand that is – coaches asking them to: Embrace change from business and at technical practices level Question traditional approaches of development Do some planning not much […]

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
3 comments Hurry up and read the full article →

Distributed Agile Patterns : Define Overlap Time

by ShriKant Vashishtha April 5, 2016

Distributed Agile teams are reality these days. For sure there are overheads. But it’s all about trade-off between ‘distributed Agile overheads’ vs combination of availability of talent at any given time, scaling teams at will and lower cost. Communication overheads are mitigated through phone/Skype/hangout calls with screen-share. It’s usual for people to do remote pair […]

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
Hurry up and read the full article →

The Secret Mantra for Agile Success

by ShriKant Vashishtha February 9, 2016

People move to Agile, go through required training and start working in projects. After a period of time, if you ask any team member, “what exactly is Agile?”, she’ll start talking about Scrum ceremonies, embracing change, shorter feedback cycle etc. Even after implementing all these aspects, you’ll find issues in that project. Why?

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
3 comments Hurry up and read the full article →