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
{ 0 comments }
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
{ 3 comments }
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.
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
{ 0 comments }
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
{ 0 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.
Hurry and Read the rest of this post!
Spread the love
{ 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).
Hurry and Read the rest of this post!
Spread the love
{ 3 comments }
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
{ 1 comment }
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 new. But does it really make sense to try and apply those known metrics to any scenario?
Hurry and Read the rest of this post!
Spread the love
{ 3 comments }
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 may be insisting you to go for full body health check up, but many fear from them as well.
Those tests will transparently tell you if anything et-all is wrong with your health. If yes, you may take corrective actions. Many people don’t go for them as they don’t want to hear bad news about their health.
You see, truth many times is beyond perceptions and feelings. Something mechanically or electronically measured is beyond feelings and is sheer truth.
Like a health checkup, software projects should also be checked for the performance of their vital organs (parameters). So that if something is wrong, that could be fixed.
Now someone may misinterpret the first Agile Manifesto tenet “Individual and Interactions OVER Process and Tools” in form of “Individual and interactions INSTEAD OF process and tools” and say, “Hey! We are doing Agile. So we don’t need Metrics. That’s so old age!”.
However truth can’t be fictionalized as has been proven in many Lean Startup experiments. Without facts, there can’t be any validated learning. Without validated learning, you never know whether your MVP is good or not.
In software development as well, one needs facts to validate the vital parameters of project delivery.
Spread the love
{ 3 comments }
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
- Do some analysis not much – leading to analysis paralysis and list goes on…
But engineering teams have to give their management:
- Long term plan
- Have to commit to project estimates at the start
- Accept all the scope changes keeping time almost same and goes on….
Saying “NO” to unrealistic expectations, scope and time is biggest cultural change. We see it so often. You can read more about this in my earlier post Sustainable Pace: Does Culture Play Any Role At All
One of the biggest myths in the industry or mis-understanding is: “Agile is for engineering teams”. It is engineering team who has to adopt to agile way of working to deliver sooner than they were doing earlier. It is them who have to accept changes from business. This kind of agile implementation fails miserably. Even business must be ready to accept surprises or changes from the engineering team. If engineering teams hit a roadblock and unable to deliver few stories(assuming product team was informed timely) then management should try to accept this. Business must be flexible to accept change.
Hence embracing change is both ways. Management can not be practicing traditional school of thought like “I want everything by this time” – “command-and-control behaviours” and expect their teams to be fast, agile and flexible.
Spread the love
{ 3 comments }