Motivating Agile Teams

How to motivate my team towards Agile?

This is a very common question that most of the managers come across when an organization or a team is in the phase of rolling out Agile processes. I must say that there is no shortcut answer to this but I would take this stand - "Don't do anything special to motivate your team towards Agile".

Forget Agile for a while. Think of any product or service that you use, for personal use or professional use. You would probably love it for its value and not because of those eye-catching presentations or speeches on them. Of course, these marketing materials would get you there but ultimately the single reason why you like it or recommend it to others is for its VALUE. Now, the same applies to Agile. Though, end of the day, motivating the team is something that a manager has to address, he cannot do Sales and Marketing job to sell Agile to the team.

First off, before trying to motivate the team towards Agile, the manager needs to answer the question, "Am I motivated?". If the manager himself is not motivated, there is little that can be done about motivating the team.

There are a few basic things that a motivated manager can consider to encourage his team and come over the resistance of the team towards Agile. Bettering is not always about doing new things, but sometimes it is about not doing a few things.

Don’t make Scrum a status meeting:

--- Every individual would have this question inside them - What’s in it for me?.

--- Prove the value of scrum meetings by asking them right questions or providing them with valuable tips that would help them think better on their tasks and make them think that they are getting real value. Offer your help wherever you can.

--- Let status be a by-product but not the intention of the discussions.

Encourage Team Collaboration:
--- Prove the value of 'team collaboration' by encouraging healthy discussions and very soon they themselves find the value of Agile by seeing the team is contributing to their tasks and and they are contributing to the team.

--- Be participative and you would sell Agile by 'Doing' it. It is a different thing that the manager is hands-on or not. (There is always a difference of opinion on this and there are varied versions of  understanding a 'self-organizing team’. But, for now, it is good enough to say that it goes with the requirements of the project and every project is different.) Irrespective of a manager is hands-on or not, he can always play a catalyst role in that he would enable the team to get the things done.

--- If the scrum meetings and team collaborations are seen to be producing results, then you are there. On the other hand, if they see it as yet another meeting and yet another process, no 'artificial' stuff can motivate them.

Create a Complementing team, not a Competing team:

I often hear the idea of identifying and rewarding the ‘Best performer of the Sprint’. Remember the intention is not to create a Competing team but a Complementing team and there is a lot of difference between these two things. The idea is to create a motivating team towards a common goal. If you introduce these ultra-short-term rewards, what happens is individuals work for their own goals. Of course, good performance has to be rewarded but Scrums and Sprints are not the platform for this.

Don't let your intentions to motivate the team turn out to be actions to demotivate the team.

If you are a manager - Are you making your efforts to motivate the team by showing the value of Agile in action?






(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Project Estimations & Planning in Agile

A valid question that is often raised is “Agile emphasizes that the Software projects are highly unpredictable in nature and Agile principles enable you handle the unpredictability better from Engineering point of view. But, from the Business point of view, how do you deal with the cost factor for Fixed Cost (FC) assignments?”. ‘How much does it cost me?’ is what the customer wants to know and ‘How many engineers do we need to allocate and for how long?’ is what your organization wants to know.

While there are a few good books available on this subject, let me try to put together a few things that I have understood from my experience.

 

Project Estimation and Planning, for most of the projects, is something which you cannot start without but cannot stick with. This is because there is always a cost factor associated with whatever you do and nobody would be ready to start the job without a plan - neither your organization, nor the customer. End of the day, it is not just an engineering problem but a business problem as well. Whether you like it or not, you need to come up with a project plan and it would give you an approximate effort estimation, if not accurate. Not only that, it also helps you understand different variables involved. But, at the end of the project, what remains true is the BEGIN and the END of the project. Everything else would turn out to be a filling-space just like a play-ground with defined boundaries(time and scope) where you make on-the-field decisions. Only question is how far the plan has changed from the original version to the end - and it depends on - How predictable the project is? How stable the requirements are?

 

Here is one approach that we used to follow for the fixed cost assignments:

---

- Provide an up-front project estimation based on the initial Requirements Analysis and the Project Scope. Provide a 10-15% buffer to accommodate for the requirements and tasks that were not identified before, but within the scope of the project. I am not saying this is the best but at least it worked for most of the assignments that we handled.

 

- This also included the Incremental & Iterative development plan.

 

- This required that we had to do a decent high-level analysis of the System to get as much a closer as possible to estimate the SIZE of the effort. For example, missing a requirement like ‘Providing User Registration Form’ in the application cannot be something that is backed up by saying that we are following Agile.

 

- As we go with the implementation and as requirements and design evolve, we had the flexibility with the SHAPE of the effort to alter the size and sequence of the iterations being Agile. This way, we used to maintain the balance between ‘Shooting in the Dark’ and ‘Shooting on the Dot’.

 

- Agile is not a replacement for capturing the Scope of the project and documenting the Assumptions and Risks. Irrespective of the format and name of the document, they need mention so that the Customer and the Service Provider can handle the things better on the estimations and the cost parts. You need to know whether you are going to implements Bananas or Oranges, where you think Bananas might change to Oranges and how it affects the Estimation and Plan.

 

- For the projects with highly unpredictable requirements or where the requirements are being developed (R & D in nature), T&M (Time and Material) or a combination of T&M and FC models are more apt. It all depends on how you work out with the customer on arriving at a consensus on what part of the project is predictable and what part of the project is unpredictable and needs R&D. It is not required that everything needs to be fit-in-one-size.

---

Apart from the approach that is outlined above, there are other approaches as suggested on this blog post (mentioned below) to handle the Project Estimations and Cost factors better. End of the day, it also depends on understanding the project variables and getting to know your customer to devise a model which suits you the best.

 

Refer to: http://derailleurconsulting.com/blog/three-contract-models-for-scrum-projects



Is your project management methodology addressing the Business and the Cost variables along with the Engineering variables?

Are you devising a right contracting method that is best suited for the project?



(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Deliver Value to the Customer

Just like you don't want to loose any customer getting in business to you, no customer would like to loose a service provider who creates value for their business. Customer retention is all about Delivering Value to the customer. Sometimes it is about understanding and delivering what the customer has asked for, and sometimes it is about proactively figuring out what the customer needs and delivering the same.

 

Let me try to put  this together with a small example from the top of my head.

---

One of our customers had a BPM tool and they were integrating their product with multiple third-party CRM, ALM and SCM tools to push the product in the market. We signed the contract with the customer to integrate their product with a CRM tool. Before the project came to us, the customer’s product had already been integrated with a leading SCM tool and we had to start from that source base.

The customer had no requirements for creating a reusable design with respect to supporting multiple integrations. Somehow, the customer had carried an opinion that writing mostly independent code for different integrations will keep them in a better place to manage the code better in that he would have the flexibility to change one integration without worrying about the other integrations. So, we too didn’t carry this discussion forward as it was not the right time considering the facts  - 1. Our team too didn’t know what were the variables of the equation and 2. There was no proper working code as a base for the discussion.

 

Here is how we approached this problem:

 
• First, we focused on these variables:
• How the existing integration was working?
• How did we need to integrate the new tool?
• For the new integration work, we implemented the necessary design principles like reusability, abstraction, error-handling and fail-safe and other things which were not respected very well in the previous integration that was already done. The new integration started working well and another tool was added to the product’s integration chest.

(As a side note - Because of the way the code was organized, a few of these things, with minor efforts from our side, came as a bonus for the existing integration. Not every single task can be billed to the customer if you are really worried about Customer Delight and Customer Retention.)

• Following this, we had a discussion with the customer on the need for reusable and extensible design - now with some working code as a base, and it was the right time for the discussion. Technically also, we had understood what precisely were the design improvements to be made.
• We worked out the details and implemented a reusable architecture for integrating more tools with the customer’s product.

---

From technical point of view, this example is about identifying and weighing the design decisions based on what-to-do, when-to-do and why-to-do as we discussed in the post - Business-Driven OR Fact-Driven Design. The rule of ‘Don’t change the working code’ didn’t apply here considering the ‘Return on Investment’ if it is overruled.

 

From business point of view, it is about identifying what the customer needs and Delivering Value to the customer. Again, this project is not one of those fortune-turner kind of projects that we handled, yet it carried some business importance and for a service based vendor, unless there is a very strong reason, every customer is as important as the other customers.

 

The design improvement added a lot of business value to the customer that they could add more tools to their product’s integration chest much faster. It is about reduced-cost and faster requirement-to-implementation cycles. The business value for us was that the customer started signing more contracts with us. End of the day. the question “What is in it for me?” has to answered for all the stakeholders. :)



Does your team understand the customer's business enough to identify what the customer needs?

Do your team's decisions on the technical aspects, also consider the requirement of delivering business value to the customer?



(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Bootstrap Agile with Agile

If your organization is planning to roll out Agile processes, take it step by step starting from addressing the process issues in a priority manner just like you handle your customer projects. Let this knowledge and lessons flow from individual to individual and from team to team until at least the processes get stabilized. Let the teams be participative in the process improvements, and don’t try to force it hard, without reasoning, and don’t forget Agile principles here as well.

 

Collaborate People:

Collaborate with the team(s) in identifying and prioritizing the pain-points of the existing process. Suggested approach is to ask stakeholders from different roles and different experience levels to participate. This will bring the possible 360 degree view.

Be ‘specific’ about the problems and the proposed solutions. Don’t use text book statements. For example, ‘Follow iterative development model’ maybe too generic solution but identifying ‘What exactly would be the deliverables’ with an iteration's code drop and ‘How should we be following up with the customer’ will be specific.

Process the Feedback:
What is that you implemented right?
What can be done better?

Let the lessons (good and bad) be shared across the iindividuals and the teams.


User Stories:
As a Developer, what is working for me and what is not working for me?
As a QA Engineer, I feel I need these requirements.
As a Project Manager, here are the issues that I would like to address.
…

Take out the Waste:

 The whole purpose of Agile is about minimizing the rework and waste and maximizing the productivity. So, implement only those principles of Agile that your team really needs. What worked for the other organizations and the teams may not be the same as what your team needs.

Example: If you don’t really need burn-down charts, don’t use them. If User Stories do not make any sense to your specific project, keep them aside. It is not just about spending time on things-of-no-use  but you are loosing time to be spent things-of-use.

Ask this simple question, “Is this method making my team do better or worse?”. Betterment is not always about doing new things. It maybe about not doing the things that-are-not-worth-doing i.e., taking out the waste.

To summarize, consider your process change also like a mini project, sticking to the basic Agile principles, processing the feedback with continuous attention with proper team collaboration. Things will fall in place in a matter of a few weeks. We may call this ‘Bootstrapping Agile with Agile’.

A process that is organically evolved would always carry more value than a process that is purely taught. As much as possible, try not to be biased by the name of the process but focus on the Goals that you need to achieve from the process that serves the interests of all the stakeholders.

 

 

What 'exactly' are the issues that you would like to solve with Agile?

What are the 'root causes' of these issues (not symptoms) so that you can plan implementing Agile from the roots? Remember it should not become yet another process.


"Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net"