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 programming. However many times, collaboration fails.
Distributed members/stakeholders are not available in time. Work, which could be finished within hours takes days/weeks of cycle time in to-and-fro communication. Product Owner is a busy person all the time. Getting hold of her becomes a very difficult task.
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.
We all know biggest risk in the product development is building a WRONG product. There are numerous examples from history to see why some products did not see light of the day or big success.
Recently, I came across a product team which took MVP approach and built a product which saw very good initial success. But with time product was unable to keep the users engaged and convert initial success to revenue to keep it floating.
Some of the questions the team started to deliberate were:
Is this a good product idea but a targeting wrong market segment….? OR
We are in right user segment but not a right product/idea – the one which does not solve user problems completely.
Implementing Agile in a big enterprise is not an easy task. The metaphor I sometimes use for big enterprise is to compare it with Elephant. It’s very easy for a small living being to move and maneuver. However when it comes to elephant, it requires time to build momentum and when it actually moves, it moves slowly.
People involved in Agile transformation get frustrated because of all perceived delays. Frustration is understandable but not sure if much can be done other than understanding the simple reality that you are dealing with an elephant and not a tiger or mouse. Hurry and Read the rest of this post!
As long as customer isn’t interested in throughput or customer trusts the team, whatever way you size or estimate doesn’t really matter. But that doesn’t happen very often. Whenever customer questions about team throughput, it becomes challenging to answer using hour-based estimation as time taken to complete any particular task deflates over time.
Some teams follow capacity based estimation technique where they identify the number of hours available in a team for the entire sprint duration. Based on that they pick up stories in a sprint. Again here as well, there is absolutely no way to know any change in team throughput as size for which capacity is defined isn’t defined. Hurry and Read the rest of this post!
Repeated software-development tasks are becoming automated through the application of Continuous Delivery and DevOps. If developers are taking more and more testing responsibilities into their hands, I wonder what will be the role of traditional (manual **only**) testing and testers moving forward?
A while back, Henrik Kniberg published an excellent case study on Scaling Agile @ Spotify. Though case study is specific to Agile scaling experiences at Spotify, some practices are equally important for smaller teams as well. This post tries to capture the essence from smaller team’s perspective.
A lot of organizations still works in functional silos.
For instance, in a bank, there may be one team for web banking, another team for home-loans and yet another one for mainframe based core-banking. Business features however in general cut across all these teams.
One of the key fundamental elements of Agile is its focus on delivering a testable or demonstrable end-to-end functional slice that provides business value. This approach is the key catalyst of some behavioural, cultural, and structural changes.
As a product owner, I am interested more in the working functionality of a product rather than the individual goals of team members. For instance, just the front-end of a user-story is of no use to me. Even if the developers finish coding, I cannot use the product if it still needs to be tested. This implicitly means that cross-functional team members have to collaborate and help each other to attain Sprint goals. Hurry and Read the rest of this post!
Often, I get to hear questions about level of details that need to go in the product backlog stories. How detailed should be the acceptance criteria? or how small the story should be? We all know stories matures with time. I really like this post on user story life-cycle. Please take time to read this. Let’s consider an example now.
User Story example: As a Project Owner(PO), I should be able to transfer complete project ownership to my connection, with my role remaining to be just a project creator(author) after transfer.
Note: At the first sight, it is tough to say whether this is a story or an epic. When this story comes up in backlog grooming meeting, teams might completely miss the magnitude of such stories. Hence, as the product becomes bigger it is wise to start detailing stories by adding acceptance criteria earlier in grooming meetings itself. Impact of every new story gets wider as product becomes bigger which often gets missed by the team.
Recently I got interviewed by DiscussAgile on a topic known by several names, i.e. Specification by Example, Behavior Driven Development or Acceptance Test Driven Development. Here’s the Google Hangout recording available on YouTube. Following topics got discussed as part of interview: Why to do ATTD? How to do it? What skills are needed to do […]
This year I delivered a presentation on “Distributed Agile Patterns” in Agile India conference held in Bangalore based on different patterns evolved or discovered during my Agile journey. The video is available now. You may want to have a look and provide your feedback.
Every Agile team has to deal with different emergencies next to their regular work. Every team dream of achieving sustainable pace comes with nightmares of production emergencies/defects, support and maintenance tasks within a sprint which takes focus completely off the sprint goals. The goal of this webinar is to see different approaches team can take […]
One of the basic but important customer expectations is – the software product should be of very good quality. That makes sense as well. However, what exactly “good quality” means? Here are characteristics of good quality software:
We know “Testing As An Activity” is important, and why we should all test. The old axiom that “Testers Test and Programmers Code” is so outdated now and everyone needs to change. Testers are the testing experts in a team, and can help enable the whole team to own quality but they are certainly not the […]