How can an Agile Leader be successful?
 

I am listing most important factors which an agile leader must focus on, in order to be successful in his/her role

  • People, people and people

  • Building Relationships with all the stakeholders

  • Business Alignment (Clarity of vision and mission)

  • Self-Organizing Teams

  • Sprint Success and Continuous Improvements

  • Everyone contributes 

  • Relationship within team

  • Collaboration

  • Promote “Fail Faster, succeed sooner”

  • Frequent releases

  • Remove impediments

  • Frequent feedback loops

  • Lots of fun

  • Process alignment

  • Visibility on current status

People

Let me tell you honestly, there is nothing more important than people.  As a leader, you should focus on people, their careers, growth, motivation and anything what you can support them to add value to their personal lives. Don’t forget to appreciate good work and at the same time it is important to provide feedback around areas of improvement.  When you think of growth, think about your team’s growth. When they grow, you grow.

Provide them opportunity to become better individuals. Inspire them to learn and get better. Feel pride in their success.

Building Relationships

Strong relationship with team and stakeholders make life easy. It’s not just about bringing in empowerment while at the same time it is important to understanding everyone’s need and expectations.  The great relationship with business, management and team helps you to have

  • Better insight
  • Access to more information
  • Align people
  • Open culture

Business Alignment and Vision

If you don’t know where you want to go, you will reach nowhere. As an agile leader, you must ensure that there is a clarity of vision and mission for you and your team. Moreover everyone is aligned to business needs and expectations. You should often ask yourself and your team about USP (unique selling proposition) of what you are building.

Self-Organizing Teams and autonomy

Don’t hold your team too tight that they can’t breathe at the same time don’t leave them to do everything by their own assuming they would become so called “self-organizing teams”  by themselves. The ultimate goal should be to build self-organizing team and if you are successful in doing so, the chances of you being successful is very high along with your team.

Sprint Success

Always focus on sprint success. When you start, do it less and then improve. Never get into discussion with business or management that we are delivering enough for our need hence meeting commitment is not important.  Do whatever it takes to make sure your sprint is successful.

Everyone contributes and Continuous Improvements

If this doesn’t happen then slowly you would see your self-organizing team start deteriorating.  Everyone has different skill and competence hence you can have different expectations while everyone has to contribute. One rotten apple spoils entire basket and this no different here.

Relationship within team

If you have happy team that gel well with each other, you are likely to do much more. If you’ve highly competent individuals in team but team members don’t go well with each other over a team which has lessor experience and competence with strong bonding then your chances of getting better output in team with good bonding. Do whatever it takes to make your team align and build a bonding among them. By doing so, you are significantly improving the chances of your success.

Collaboration and Communication

Agile team cannot run in Silo. The collaboration nothing but working with cross functional teams to accomplish a task. This encourages communication among business owners.  The communication within team is also very important. The output will be produced by team and not individuals.  It helps in removing impediments faster as well.

Promote “Fail Faster, succeed sooner”

It’s not a perfect world. In order to be successful with Agile there should be an environment where everyone encourages individuals to experiment. It’s OK to fail and that’s what lead us to be successful.  Fail faster, succeed sooner is something you should not just feel while you are expected to enforce that in your team.

Frequent releases

Release as much as you can. I have seen teams releasing every day or even post every feature completion. This is a challenge at a times or product which are quite big and needs significant testing. More you do, simple it becomes.  The moment you start thinking about releasing frequently, you would focus on automation tests.  That something most times become last priority which is not at all good.

Constant feedback

Don’t wait for showcase to provide feedback. The code review phase is not important to provide the challenges or best practice. Talk more. Provide feedback then and there. Look for ways to get the feedback from customer, PO or other stakeholders as soon as possible.

Lots of fun

Start with fun and then get on to work. Don’t wait for you to be successful to have reward. There is going to be celebration for that as well while create an environment where everyone feels comfortable and enjoy working.

Process alignment

Arrange a training. Talk about process. Doing agile is probably easiest thing while doing it RIGHT is what really needed right mindset. There are many teams I have seen they do “waterfall agile”. They are basically trying to do waterfall within each sprint.  Not good!

Visibility on current status

Create various matrix to ensure things are on track. Utilize standard artifacts like burndown charts, velocity report etc to see where you stand. You can fix the issue and come up with finding a right solution only when you know how are you doing.

Agile Abuse – Scenario 7
 

Neha – Developer 1, Bob – Product Owner, Peter – Agile Coach

Neha – We are always missing acceptance criteria and functional details in a story. It is really tough to commit a story with little or no clarity.

Bob – The Agile lets you to evolve the requirements as you move. This is perfectly alright.  I am within the boundary. I will write acceptance criteria when I get the time.

Peter- The requirements can evolve and that’s advantage for a customer while stories cannot keep evolving during the sprint.  You have an opportunity to refine the acceptance criteria. If the functional requirements are not clear or acceptance criteria cannot be determined during planning/grooming, the story shouldn’t be committed. It should be moved for a later sprint.

Bob – Can I write the acceptance criteria and later change it altogether during sprint as we progress?

Peter – No for sure. The change in a story once committed is a “scope creep”. You must move that to next sprint of post re-estimation, you might have to remove some other stories out of a sprint. Ideally, you are not allowed to change anything during a sprint. Adding more details to acceptance criteria to to make it more clear as you move should be fine, though.

Bob – Fair! I will take out the stories where I don’t have clarity.

Challenge – Writing one liner description for a story should be fine and we will keep looking at it while working in progress during the sprint. 

Agile Abuse – Scenario 6
 

Sumant – Developer 1, Veena – Scrum Master

Veena – Sumant, we are almost at last day of sprint and your 3 pointers are not yet done. Do you see a risk? What is the tentative time you think you would take?

Sumant – I can’t tell you. Agile says that you cannot convert story points to time hence 3 pointers can take 3 days or 3 months. All valid in agile.

Veena – Why do you estimate your stories?

Sumant  – So that we know whether we can do that in our sprint or not.

Veena – And a sprint duration can be 3 months too?

Sumant – Oops, I got it.  My bad!

Challenge – Story point is not about time, not even a range.

Agile Abuse – Scenario 5
 

Ron – Developer 1, Amy – Scrum Master

Amy – How come we committed 45 story points and we accomplished 51 though I have not added any extra work to sprint.

Ron – The performance improvement story was little complicated hence I have added 6 additional points to it.

Amy – Once an estimate is done, it is not supposed to change in any case. If so, the whole point of estimation has no value.

Ron – Sorry, I will change that back to original and add the challenges encountered with that story to our process asset library.

Challenge – It is perfectly alright to play with estimation at any point in time.  

Agile Abuse – Scenario 4
 

Paula – Customer, Amy – Manager

Paula – Amy, you mentioned that Agile is supposed to be faster. Why don’t you speed up the work with the same team? Sprint velocity is supposed to be must faster sprint after sprint and the speed of work should constantly increase.

Amy – Too much of speed can affect the quality of work. Agile promotes sustainable development. In a long run, the overall benefit with respect to quantity or quality is going to be more in most circumstances while the sprint can run with a pace and all you can expect is little improvement sprint after sprint.

Paula – OK. Got it.

Challenge – ‘Sprinting’ means running super-fast.

Agile Abuse – Scenario 3
 

Ron – Manager, Amy – Scrum Master

Ron – Amy, why the heck stand-ups are going for an hour every day.

Amy – The team prefers to talk and sort out open items. Although there is some unwanted discussions as well but that is just to keep morale up. It is truly helping us to sort out open items every day.

Ron – There is something wrong here. Are the questions being asked or clarification expected common to all?

Amy – Not really. Once in a while, it is general but typically it’s between two people.  It helps everyone to get the perspective.

Ron – You really need to take those discussions offline. The standup is supposed to end in less than 10 minutes (Worst case 15 minutes) for 10 member team.  You can do planning or grooming once or twice a week but that must have to be separate meeting and not a standup.

Challenge – A standup cannot be a meeting.