AGILE Mindset

Do your project teams have an AGILE Mindset?


Delivering projects using AGILE as a methodology is no longer 'one' of the options. It is the 'only' option especially for Organizations engaged in IT services, Product & Mobile App development. For that matter, even Organizations in other sectors like manufacturing, Infrastructure and even Consulting are considering delivering some of their projects in an AGILE way.

Many Organizations who have implemented AGILE as a methodology have fallen back to other traditional methods or are struggling to make it a standard practice. Having seen a number of AGILE projects from the inside and outside, I have a few thoughts on the common mistakes made by Organizations and project teams when delivering projects the AGILE way. If you are considering going the AGILE way or have encountered challenges while implementing the AGILE way, I have a few probing questions for you. The answers to these questions may hold the key for a successful transformation into AGILE.

1) AGILE is more than a process & methodology. AGILE is a Mindset

An Organization cannot deliver projects using AGILE methodology unless every part of the Organization develop an Agile mindset. If the requisition for new software, for example, is going to follow multiple layers of approvals and no accountability on closure, how can that Organization ever hope to deliver projects in an AGILE mode? The AGILE way of thinking suggests that a minimum viable product/solution needs to be delivered in the least amount of time. Does every employee in your Organization think that way?


2) Clarity of roles

The standard practice followed by most Organizations going the AGILE way is to send existing Project Managers to a Scrum training and get them certified as CSM's. Business Analysts with client experience are identified to play the Product Owner roles. The Scrum Master role is very different from that of a traditional Project Manager and so is the role of a Business Analyst from a Product Owner. Even the role of the development team members is so very different in AGILE. Is there enough being done to onboard employees into these roles and provide this role clarity?


3) Being too ambitious

The general perception is that if a project has to be delivered 'yesterday', use AGILE. Agreed that AGILE does help in reducing the overall duration of a project by delivering smaller pieces of work at regular intervals, it is not a magic wand which can be waved and everything will fall into place. The same ambition is seen when the AGILE teams finalize the scope of every sprint. Is there pressure on your teams to take too much on their plate which inhibits value delivered to customer?

 

4) Every meeting has a time and duration

The AGILE methodology does prescribe a few mandatory meetings like the Scrum meeting, Product backlog reviews and so on. However, it is common for Daily Scrum meetings to drag on for hours or sprint reviews being done a few days early, but then not having everything ready to demonstrate. AGILE not only prescribes the objectives of every meeting but also the duration. Are your teams following this strictly?


5) Telling people what to do

This is one of the biggest mistakes which can spell doom for an AGILE project. Since most Scrum Masters have been traditional Project Managers, a number of habits they have employed in the past seeps into the current AGILE project. Some Scrum Masters have even reported the opposite problem, saying they remained too silent during team discussions. Are your Scrum Masters trained on People engagement concepts like Servant Leadership which is the real essence of AGILE?

 

6) Unjustified Prioritization

Customer priorities change. Customer requirements are not always well articulated. These are some of the common challenges in any project. The very construct of AGILE is supposed to address these and other challenges. However, that does not mean that a User Story gets accepted without enough clarity just because a Product Owner wants it that way. Are your Product Owners being unduly influenced the customer teams which impacts the value delivered?


7) Trying to fill every hour with planned work during sprint planning

Organizations are so worked up on Utiization that project teams refrain from showing any unallocated time in their project scheduling and execution. When sprint planning is done and a few Dev team members seem to have some un-utilized hours, there is pressure to fill this time with some activity and thereby overloading the sprint. Are your teams planning their Sprint without this pressure?


8) Not asking enough questions

In a traditional project, most of the decisions are left with the Project Manager and the team members have not developed a habit of asking questions to the Scrum Master and Product Owner. Since AGILE requires the Dev team to understand, estimate each User story and assign them to self, they need to ask enough clarifying questions. Does your Organization culture support this need?


9) Not complying to the process

The Scrum framework is a light-weight evolution of the traditional Project Management methodologies and includes the bare minimum but mandatory processes which determine the success of a project. Many project teams tend to take further short-cuts by leaving out some meetings because their teams were 2-3 people. This is a recipe for failure. Do your AGILE project teams comply to the prescribed processes and it there a way to monitor the same?

 

10) Not pushing themselves harder

The AGILE mindset revolves around self-allocation of tasks and then ensuring complete ownership until it is completed. In their retrospectives, some project teams choose to lessen their own burden by choosing improvements which are easy rather than the one's which create more value. Do your AGILE project teams not push themselves to deliver highest Customer value delivered?

 

11) Not letting go of a mistake

This is a classic. The fast-pace of an AGILE project delivery and the lack of traditional Manager may lead to mistakes. Incorrect Story point estimations, too optimistic Sprint plans etc. The AGILE framework allows for these mistakes to be corrected in subsequent Sprints but the danger is that a number of people tend to replay mistakes in their heads or let mistakes gnaw at them. Do your AGILE project teams understand that making a mistake and learning from it is an integral part of AGILE delivery?


Does your Organization deliver projects or is considering delivery of projects in an AGILE mode?

Wouldn't it be wonderful if your Scrum Masters, Product Owners and Dev team members are given an opportunity to experience all the above scenarios, understand their natural responses, learn from the consequences and accordingly make the right choices in their real projects?


Wouldn't they be more ready to delivery more profitable projects for your Organization?

Prosim AGILE, a Digital Simulation product of SimWorks provides this wonderful experience. We would be happy to come over for a discussion


Coach-Ram

coach-ram.in

Comments

Post a Comment

Popular

Science of Influence

One of the traits that Project Managers or any Leader needs to develop is the ability to influence. Every project ecosystem consists of Stakeholders, internal and external. These include your own team members. The ability of a Project Manager to influence these Stakeholders will ensure that the project is in control. Dr. Robert Cialdini has developed 7 principles of influence which can be used by Leaders to influence others. 1.  Reciprocity :  When you do people a favour, they tend to respond in a manner you want them to. However, there are some points to note. - I t’s not about what is given, but HOW AND WHEN IT IS GIVEN . Be the first to give the favour. - Let it be personalized and unexpected. Tell them ‘ I am doing this only for you ’. Suppose, you have done a favour to a person and he/she says ‘Thank you’. What is your response? Many of us say, ‘Its okay’, ‘It was my duty’ etc. Some rare person may say ‘Now you also owe me a favour’.  Instead use this principle Respo...
Read more

CONFLICTS in Teams - How to address them?

Conflict on teams is inevitable. But here’s the real question: does it need to be resolved? Not always. In fact, the type of conflict matters just as much as how you address it. Some conflicts demand immediate resolution, while others can be channelled into creativity and progress. Knowing the difference is critical to leading a team effectively. At its core, conflict on teams falls into two categories: personal conflict and task-focused conflict. Personal conflict is what most of us think of first—tensions that get personal, unkind remarks, or behaviours that erode respect. Left unaddressed, this type of conflict undermines trust and productivity. Task-focused conflict, however, is entirely different. This is the natural tension that arises from diverse ideas and perspectives. It’s not a problem to be solved; it’s a tool to be harnessed. Handled well, task-focused conflict can propel a team forward. Let’s look at both in depth—how to resolve personal conflict and how to channel ...
Read more

Application of Scrum Values

The essence of Scrum are the 5 values. A Scrum-Agile project will not be successful unless these values are demonstrated in every event, while preparing every artefact and while performing any role. In fact, these values can be demonstrated in any environment to reap benefits. Here are 10 practical instances for each Scrum value that any team can demonstrate: COMMITMENT Team members dedicate themselves to achieving the team's goals and doing their best work. They commit to the sprint goals and support each other in meeting those commitments. Team commits to delivering specific user stories in the sprint backlog, even when facing technical challenges or scope creep requests from stakeholders. Team members commit to rotating on-call duties to ensure continuous support for critical production systems across different time zones. When a legacy system needs modernization, team members commit to learning new frameworks or cloud technologies requ...
Read more