Fix bid (Agile) project. Are you ready?

What is a fix bid (Agile) project?

This is a general understanding that fix bid project means fix price, fix time, fix scope and obviously with quality. This requires detailed and accurate requirements. ‘The IRON TRIANGLE’…

However a ‘Fix bid AGILE project’ is bit different from the above understanding. How? We will see it in the later part.

Now let us understand why customers ask for fix bid project?

·         Many customers do not have significant idea, what agile means. They think that from an agile project they will get iterative deliveries hence more control on project and less surprises at later stages.

·         Customers do not want to take any financial risk.

·         Customers (generally government institutions) need to choose between bids. They have to stick with fix bid project which also needs to be agile.

·         Lack of trust between Clients and Contractor. And this is obvious as every time the projects are not from the same clients or from the clients which know enough about contractor prior to the project.

What benefits a contractor may anticipate from fix bid project?

Not all the time but at times contractor also gets benefited from fix bid agile projects.

·         A contractor can predict his cost and benefits.

·         Planning in a fixed price project is easier. As cost and benefits are predicted in advance, the other planning as scheduling and resourcing becomes easier. Contractor can focus on other projects easily as fix bid projects scope and timelines also are fixed.

·         Generally this happens when the domain is well known to contractor. If the contractor is selling its product then the expertise is already with contractor. Say, if we are selling our own product (company’s product) then we already have enough expertise and SMEs with us. We know almost all features/functions in advance. Yes, there may be a few customization needed as per the client’s requirement. If planned well, we can go ahead with fix bid agile projects.

What should be the way of collaboration between client and contractor?

·         First of all client should know what Agile means and how an agile project will be developed and delivered.

·         Preferably a Product owner from client should be available, if not, contractor may provide agile training to a SME (Subject Matter Expert) - a representative from client. If this is not possible, offer client a proxy Product owner.

Fix bid AGILE project

In most of the cases client is more focused on TIME (Deadlines) and BUDGET. So the only option left flexible is SCOPE. Though clients forces for fix SCOPE also but in Agile project the scope is drilled down from VISION to Stories (even more up to tasks). So once we discuss about the scope, we could provide client a range of Stories expected to be covered in the Fix Time and Fix Budget. Sometimes stories may still be in form of EPIC (Big story).

It had been debated many times that Product owner from client asks for inclusion of more and more stories in sprints. In such cases ScrumMater and the team can guide Product owner about the team’s capacity. In my opinion if the team (Product owner, ScrumMaster, Development team) is working in collaboration such things could be tackled easily. After all Product owner also works for success of product/project and he/she responsible for the same. :-)

How to deal with Change requests

Change is inevitable. Agile welcomes Changes and that is the essence of Agile. However in Fix bid it creates confusion.  Change is inevitable but BUDGET is fix :-).

The best way to deal with Change request is to drop comparatively less important user stories (equal story points which the change request have). Having fix bid project, it becomes tough to convince clients. If you could do that, go-ahead, get some more bucks from client.

More on how to judge importance of a user story can be found at:

https://www.scrumalliance.org/community/articles/2015/january/product-backlog-refinement-and-prioritization-with

The Monster of Cross-Functional Scrum Teams

The question here is- Are we using the right environment to create teams with cross-functional, T-shaped skills?

We see many instances in new Scrum teams in which team members don't work on skill sets other than their own core skills. I have heard such concerns from many ScrumMasters. This is a situation where you will find that it is not easy to create a cross-functional development team with a T-shaped skill set.

If we inspect closely, there are many reasons behind this unwillingness from team members, which need to be addressed prior to attempting the creation of a cross-functional, T-shaped development team.

Let us imagine what the scenarios might have been when you tried this experiment with your team:

• Hey Bob, could you do testing along with Chris, as Maria will be on leave for the next four days?
• Trisia! You're leaving us by next month and Mak will be on this project, and it would be great if you could help David in executing the test cases.
• Brad, you have worked very well in this .net MVC project, but the integration part in php is not doing well. Because you've previously worked in php also, can you please start looking into that? You may devote 60 percent of your time in that module.
• Hey Paul, please work on data migration till other functional requirements are ready to be discussed.

There may be a lot of other scenarios within teams you worked on or might have seen in other teams. (Please add your thoughts in the comment section below.)

What do you think went wrong in scenarios above?

Generally in newly formed teams, we ask a developer for help when someone with that skill set is not available or when it is discovered, at an advanced stage, that more help is needed to complete the sprint tasks. Usually this leads to stretching working hours. I have generally found that in newly formed teams, it works adversely to burden someone in pretext of asking for his or her help.

Sometimes a developer doesn't bring up the fact that he or she doesn't have adequate skills in a required area. Hence it makes sense to indicate that appropriate training will be provided prior to assigning him or her such tasks. Also, we need to assure these developers that their core skills will always be considered when assigning tasks. In mature teams, we rely on task "pulling," but initially in new teams it's task "pushing" in the forming stage.

There is always a fear that working on a different skill set will lead to work on other skills only, and no longer on core skills, especially if there's a scarcity of experience on the team with that needed skill set. However, developers should not have to fear that they'll be spending most of their time on the "other" skill set at the expense of their core skills. This can hamper their ongoing improvement in their core skill set and prove demoralizing.

Often such situations lead to job hopping instead of creating cross-functional teams.

See more at: https://www.scrumalliance.org/community/articles/2015/march/monster-of-cross-functional-teams