Critical path in Agile Projects?

This is a question I had in my mind for some time. How do we tackle the critical path in agile project? do we really have a critical path in Agile? or is it implied by another element of Agile? I think the answer is this. This was explained by one of my mentors and I think it clears out lot of doubts I had in my mind.

Lets talk about traditional project management triangle. See below.

 

In traditional context we know what the scope and the budget is and the challenge is to deliver. We then workout a plan and draw the network of the work to be done. Since the time is the driving force we determine the critical path. It is basically we are hunting for a project deadline than trying to reshape the scope and cost. Therefore critical path plays a major role in traditional project management. 

Qualifying Quality Vs Winning Quality

It all depends on the market we are competing. If we are dealing with a highly competitive market where the requirements are driven by the customers then we will have to find non conventional ways to make them 'very' happy. However before we make them very happy we need to make sure that our solutions at least can do the job for them. Even though we have done all the due diligence to get their requirements working its does not mean that customers are 'very' happy about the solution. This is the difference between winning quality and qualifying quality. Just take a look at the following illustration which was copied from internet.

Source Unknown

This exactly what we should be doing as quality engineering. Conventional schools will teach us to meet the customer requirement which may be in the form of either user stories or requirement specification documents.

Must be the worst test plan - enjoy

 

 Source: https://www.youtube.com/watch?v=7QCkK_p6TZA

This not a descriptive post but this reminds me there is worst testing challenges in the world that what I have today :).

What leadership styles is right?

What is the best leadership Style? OR What is the most suitable leadership style?

These are the two questions I have in my mind. Can we really say a certain type of a leadership style is better than another? or it is merely depends on the context. 

Leadership styles are enormous and it certainly depends on individual traits. However as per literature this can be modeled into few key styles. I have seen different leadership style of my bosses and in fact it is one of the reasons to write this post too.

Below image clearly demonstrate what we know today. I am not going to talk about each and every crisis as they are self explanatory. However lets not worry or think a lot about this model. This is just a supporting illustration for the article.  

Source: newswire.net

Limit of training

This is a very interesting subject to discuss. How much training is sufficient for a job is a very good question to ask. We first need to determine the desired level of talent for a particular job and then do a gap analysis. Training is then designed to bridge the gap identified between the desired level and the actual level. It looks alright with but there is a problem with this model that is whether training itself can address the gap? lets talk a little bit about this.

Source: Emaze


We need to discuss this in two dimensions

1. No matter how good the training is there is always something else needed to bridge the gap! or in other words training itself is not sufficient!
2. Not all the training are good. Bridge cannot be narrowed by training because of the problems within the training itself. So what is the easiest and best way to address this point.  

Lets discuss these points.

This is funny but has some meanining too

Time for a bit of fun..This one was downloaded from a Facebook post. This is funny and of course exaggerated. However just thought of sharing my view on this. I truly think that what is discussed here is connected to the Mythical Man Month book I shared in a previous post. Just remove the fun items for the time being and focus on the underlying point - there is a overhead in a team and better work alone. Well, we must need teams in our work but lets reflect on the team overhead.

As per the learning from the mythical man month book, I think some overheads are inevitable and we will have to manage them. For an example if the tasks are interrelated and needs communication between engineers then no option we must expect some slowness. That is natural but there is something else we need to look into that is social loafing or in other words free passengers. This is can be avoided by having proper team composition and size with right leadership to the team. 

Food for thought when prioritizing

One of my colleagues shared this matrix which looks really good. What I like most is the "Low Hanging Fruit" which is ideal in an Agile development. It is nothing big here. All what it says is delivery things fast and lets think of what can be done easily to add value to our customer experience. 

However there is a trap with this model. Sustainability is not taken in the consideration. Ideally it has to be the third dimension. What could potentially happen is that Product Owners will pay more attention to high impact features but it may compromise the stability and the robustness of the software system being developed. However if the below matrix is only for consumable feature and we treat the tech debts, sustainability items, serviceability items and maintainability items separately then I think we do not have any issue.  

Enjoy!