Being Agile: Team Got To Know Its Limitations

#SridharPeddisetty #Agile #BeingAgile #Scrum #Motivational #ProjectManagement #Management #AgileBestPractices #Team

"A man's got to know his limitations”, a quote made immortal by Clint Eastwood in the 1973 movie Magnum Force. I am not a movie buff but do like to rewatch classics once in a while and the inspiration to write this blog came right after watching Clint deliver his famous one liner. While adopting Agile development practices, its often seen that Organizations have a great deal of passion and good intentions. But unfortunately the intent alone is not enough if the attempt involved either the adoption scope to be too large or at a pace too fast for the organization, whose culture is not ready. 

For successful adoption of Agile across Organization, its important to start with one or two pilot teams. For the team to be successful in adopting Agile practices, its important to get to know its limitations. Intimately knowing and addressing team limits, a lot could be truly accomplished. Below are my tips in identifying team limitations and playing to their strength for successful adoption of 'Being Agile'. 

#1. Deep philosophical understanding of Agile: In my earlier post An Agilist Needs More Than Training To Succeed, I had shared that getting trained in Agile does not necessarily mean that we have started thinking ‘Agile’. After training, it is important to work in your Org towards bringing in changes including predictable delivery by taking small steps in developing an environment, which fosters a collaboration culture with a shared vision across the Org. 

#2. Get familiar with individual team skills: Agile encourages team to consist of self performing & cross functional team members. Its important to understand the skills of each team member including front end, back end and other needed skills in the sprint (or) project. While grooming or planning, its essential to identify and play to the strengths of individual team members.  While finalizing the team, one needs to be very clear what the objectives are and what they need to deliver individually as a member and collectively as a team.

#3. Set clear goals for the team: Its vital for each member to understand how their individual goal fits into the overall objective. For a team to be highly productive, its vital for them to understand what they are delivering as a team and how the deliverables are going to be measured. A team, which understands the importance of what they are delivering will always be highly productive and will adhere to much higher standards than one with no clear purpose. 

#4. Provide team the necessary tools: Performance of any project team is only as successful as the weakest link in the team. So we need to constantly nurture the individual team members while providing the necessary tools to be productive. For instance, once we have identified the weakling, its necessary to plan the mitigation either by pair programming or mentoring by cross training or guiding. Keep in mind that a happy team would automatically take care of keeping your client(s) happy so its important for the team to be equipped with right & necessary tools.

#5. Build in culture of continuous improvement: Its essential to create a robust environment where feedback is encouraged, appreciated and taken (or) given on a standard basis. Without proper guidelines, measurements and feedback, it is very easy for team to fall into a spiral trap of stress, demotivation and rapid disintegration. When the right culture of continuous improvement is put in place, it always guarantees a well-functioning, highly motivated and goal-driven team. 

Summary

While the practitioners of Agile are still divided into teams that are highly productive ‘Being Agile' and teams that are not. In my experience, team is successful in adopting Agile when it understands well its limitations and plays to its strength within the known constraints while continuously striving to improve. Teams that usually fail in adopting Agile successfully or struggle in their adoption are the ones that are usually leaning towards why something will not work rather than working on finding solutions to the constraints. 

Share your thoughts in the comments sections to the best team management practices you employ while practicing Agile. 

Previous posts you might be interested in

• Active Listening Is Key For A Successful Delivery 
• Kanban & DevOps - Forming A Perfect Alliance
• An Agilist Needs More Than Training To Succeed

Being Agile: Best Practices For A Retrospection

#SridharPeddisetty #Agile #BeingAgile #Scrum #Motivational #ProjectManagement #Management #AgileBestPractices #Retrospection

"While some of us learn from the mistakes of others; the rest of us have to be the others!"

Being Agile is not just about processes, tools, bunch of smart technical people coming together & figuring it out all by themselves on what business value to deliver. Being Agile is about aligning the core Agile principles with the Org strategic goals and then enforcing the following of those core principles in delivering business value in an iteratively incremental manner. 

What is Retrospection?

By definition, retrospection is the action of looking back on or reviewing past events or situations. In the context of Agile, retrospective meetings are held at the end of an iteration or sprint. During the retrospective, the team reflects on what went well in the iteration or sprint and identifies lessons learned & actionable items for improvement moving forward.

Why Retrospection?

If you cannot measure, you cannot improve. Retrospection helps you provide a platform to measure your current status with the goal(s) and an opportunity to do course correction. In my earlier post Everyone's Perspective Is Key In Retrospectives, I had shared why its very important for everyone’s inputs to be considered during the retrospection. 

Best Practices for Retrospection

While working on any project there are 4 major components

1. People
2. Process
3. Technology & 
4. Tools

For having a productive retrospection, my recommendation would be for retrospection meeting participants to come prepared with some specifics in terms of above components. Keeping above components in mind, team can be specific about what went well in sprint or project, things that can improve for next sprint or project. For instance, some discussion points could be around following 

                   

                    People

• Did we identify all the right skills needed? 
• Did we mentor the team members as required?
• Did we follow RACI matrix as agreed upon?
• Did we manage stakeholder's expectations as per Backlog/SOW?
• Did we address team’s or individual impediments in a timely fashion? 

Process

• Did we use follow best practices in delivery process?
• Did we implement identified improvements in past retrospection? 
• Did we standardize our meetings to measure progress & concerns? 
• Did we practice continuous improvements? 
• Did we address any redundant process(es) that can be discarded or improved upon? 

Technology 

• Did we align technology solutions for optimally delivering business value? 
• Did we use coding best practices? 
• Did we follow technology best practices?
• Did we use good DevOps, build, deployment & automation best practices?
• Did we employ engineering practices like pair programing, peer code review, etc.?

Tools

• Did we make the best use of relevant tool for managing requirements & measuring progress?
• Did we make the best use of relevant tool to efficiently measure quality of our code?
• Did we make the best use of relevant tool to measure our testing to ensure quality alignment? 
• Did we make the best use of relevant tool to provide communication transparency on status, quality, etc.?
• Did we make the best use of relevant tool to optimize collaboration among team(s)? 

Summary

Its important for us to celebrate our successes & failures and retrospectives provide us an opportunity to do the same. 

“You can never make the same mistake twice. The second time you make it, its no longer a mistake, its a choice.”

Share your thoughts in the comments section on the best retrospection practices you employ while practicing Agile. 

Previous posts you might be interested in

• Active Listening Is Key For A Successful Delivery 
• You Already Have ‘NO', Go For ‘YES'
• Every (Failed) Project Has ‘Success' Story To Tell 

Everyone's Perspective Is Key In Retrospectives

#SridharPeddisetty #Agile #Scrum #Retrospection #Project #Retrospective #Management #BestPractices #ProcessImprovement  

In the early 20th century, an Architect and an Engineer entered a fancy hotel with a roll of blueprints to investigate how to add an elevator to the building. As they were measuring and planning where to knock holes in walls, the Janitor walked up and asked what they were doing. They told him that they would be installing a new elevator in the building. The Janitor quipped, "That's gonna make quite a mess."  Both the Architect and the Engineer assured the Janitor that he would get help cleaning up after they were finished. The Janitor scoffed: "I don't know why you want to go through all that trouble. If it were me I'd put the elevator on the outside of the building and save the fuss." The Engineer looked at the Architect and they were dumbstruck--and the elevator on the outside of a building was born.

Introduction

People with a different perspective can come up with some incredible ideas. Above is an example of an incredible idea, which goes to show that everyone’s inputs are equally important. Even though most of us understand this well, sometimes during retrospective meetings, the Scrum Master or Facilitator fails to have all participants share their thoughts. Not everyone in the team is an extrovert or feels secure enough to share individual opinions in front of others. So the onus lies on the Facilitator of the retrospective meeting to ensure everyone’s perspective is taken. 

Tips on taking everyone’s perspective in retrospectives

Below are 5 tips on how to take everyone’s perspective in a retrospective meeting

Tip#1: Ensure a comfortable setup

Whether doing retrospective with co-located team or a remote team, it’s important to have a meeting setup, which instills comfort for the participants. Personally, I have seen retrospectives done over video conference where some participants are not visible on the screen, which makes it uncomfortable for some to speak while not being visible. Ideally, retrospectives should not include anyone who is not going to contribute. Some members could possibly feel uncomfortable speaking in front of an audience who are not part of the team or does not have anything to contribute in the meeting. 

Tip#2: Share all relevant data ahead of time

Provide an opportunity for participants to be prepared for the retrospective meeting. Normally the tool provides visibility of the goals for a sprint or a release and the actual deliveries. It helps to summarize what was planned, what was achieved and other relevant details in the agenda so that the participants can come prepared with their thoughts to share. It also helps to share the status on action items ahead of time and what has been accomplishment in terms of continuous improvement from the lessons learned from the past retrospective meetings. 

Tip#3: Encourage participants to share thoughts without interruption 

We understand that not all technically skilled resources have good soft skills and some struggle to take time to explain their view point. It’s important to time box but at the same time a good Facilitator understands how to encourage participants to share their perspective. A Facilitator can ensure that someone is actively taking notes for future reference as needed. The Facilitator can also help in ensuring that technical details are understood by the non-technical participants. 

Tip#4: Facilitator should be unbiased  

The Facilitator should direct the conversations to encourage participants remain focused on the objective of the retrospective and ensuring that thoughts are challenged as needed and not the people. No side conversations or comments should be encouraged while a participant is sharing thoughts. The Facilitator should ensure that participants’ thoughts are respected and people can disagree without being disagreeable. 

Tip#5: Encourage consensus on action items

The Facilitator should ensure that there is a consensus on actionable items and identify the owner of the respective action item before wrapping up the meeting. Having a consensus encourages participants to think for themselves as a team. The Facilitator should also summarize main points discussed in the meeting and later follow up with an email or publish in a tool including meeting minutes. 

Summary

The best teamwork comes from the team members who are working independently but toward one goal in unison and working in an environment where everyone’s perspective is encouraged, heard and respected. 

Previous posts you might be interested in

• Active Listening Is Key For A Successful Delivery
• 5 Reasons To Let Your Team Struggle Today
• 20 Guidelines For A Productive Meeting

Everyone's Perspective Is Key In Retrospectives was originally published under Prokarma blog on Oct 26th 2015

Where Scrum Falls Short, Scrumban Comes To Rescue

#SridharPeddisetty #Agile #Scrum #Kanban #Scrumban #ScrumFails #ScrumDoesNotWork #ScrumPrinicples #ScrumbanPrinciples 

What is Scrum?

Scrum is an iterative and incremental lightweight Agile based software development methodology, which is based on following core principles:

• Scrum employs transparency, inspection and adaptation through its ceremonies (Daily Scrum, Sprint Planning, Sprint Review & Sprint Retrospection)
• Work is organized in time-boxed cycles (2-4 weeks) referred commonly as Sprints
• Product Owner defines the Sprint goals and shares during the Sprint Planning ceremony 
• Product Owner defines work goals through user stories and prioritizes them during the Sprint Planningceremony
• Scrum Team are cross functional and decides how many user stories it can work on in a Sprint during theSprint Planning ceremony 
• Scrum Team are self-organizing and estimates how much time each user story in the Sprint will take during the Sprint Planning ceremony 
• Team member with specialized skill(s) can decide how to do the work for each user story but overall accountability of delivery in the Sprint lies with Scrum Team
• There is no interruption for the Scrum Team during a Sprint and its the responsibility of Scrum Master to ensure that
• Scrum Team is answerable to the Product Owner for Sprint deliverables while Scrum Master plays the role of a Servant Leader
• Scrum Team measures its performance by tracking Velocity during the Sprint
• Scrum Master is responsible for removing impediments for the Scrum Team that could be shared during Sprint ceremonies or through osmotic communication

What is Scrumban?

Scrumban combines the core principles of Kanban with some of the core principles of Scrum. In my earlier post Kanban & DevOps - Forming a Perfect Alliance, I had shared the basics of Kanban, which includes:

• Visualize Work In Progress (WIP)
• Limit the WIP
• Maximize Productivity (by minimizing lead time)

Essentially in Scrumban we employ Kanban's ‘pull’ approach rather than Scrum’s ‘push’ approach while using theScrum principles with some modifications. So core principles of Scrumban translates to  

• Sprint – In a Sprint instead of limiting it as time–boxed, team ‘pulls’ prioritized ‘just in time’ (JIT) work items in the Sprint based on team's bandwidth. In other words, Sprint is ‘limiting the WIP’ instead of time-boxing the Sprint
• Sprint Planning - In the Sprint Planning, team plans for JIT work items. Since Sprint is not time-boxed, team does not necessarily spend time on doing estimations but rather focus on understanding the work item goals, dependencies and how to do the work
• Daily Scrum – Team continues with Daily Scrums answering basic 3 questions  

                 o    What did they do since last Daily Scrum? 

                 o    What is the plan to do till next Daily Scrum? 

                 o    What are current impediments (if any)? 

• Visualizing Work In Progress (WIP) - Team uses board to visualize JIT work items including the respective state of the work items and swim-lanes they belong to 
• Sprint Review – Team uses Sprint Review for showing demo of work items to the concerned stakeholders & 
• Sprint Retrospection – Team uses Sprint Retrospection for doing retrospection, providing an opportunity for continuous improvement. Ceremony can be used for identifying bottlenecks and opportunity for optimizing the work flows. In my earlier post 'Metrics For Maximizing Productivity In Kanban SDLC’, I had shared on how to maximize productivity in Kanban SDLC

Where Scrum Falls Short?

Scrum falls short when team spends too much time upfront in doing Sprint Planning and in the middle of the Sprint, there is a priority change for one or more User Stories. In some situations, an entire Sprint could be cancelled by the Product Owner or the Management for various reasons including budget constraints, change in priorities or the work items in Sprint are allocated to another project team. All this not only impacts team’s productivity but also at times the morale of the team. Another concern commonly heard in Scrum Retrospections is that the velocity is not helping do accurate estimations or the Sprint backlog is not achieving desired forecasting. Lastly, in my experience I have seen some teams following Scrum fixated on following the “process" rather than focusing on delivering value.    

How Scrumban Come To The Rescue?

Since Scrumban is based on the lean principle of focusing JIT work items, team remains committed to the WIP. Scrumban provides the flexibility of prioritizing and reprioritizing work items and since team is not doing any heavy lifting of upfront planning, they remain focused on delivering value faster. Scrumban also provides the flexibility to the team for switching gears to work on expedite work items which is not possible in Scrum especially when in the middle of a Sprint without causing some serious feathers to ruffle. Lastly, since Scrumban is based on Lean values, it focuses less on following the ‘how of the process’ and focuses more on delivering the value through continuous improvement. 

Summarizing

In summary, Scrumban is a lightweight SDLC process that combines Scrum to be more Lean & Flow oriented. In Scrumban, team achieves optimized productivity by remaining focused on JIT work items and faster cycle times. Team gets better at spending less time in doing deep dive up front estimations and instead uses more cycle-time based forecasting, which provides team with more time in actually delivering quality work item.

I will be sharing case studies, process improvements and best practices specific for Scrumban in my future posts. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com 

Where Scrum Falls Short, Scrumban Comes To Rescue was originally posted under Prokarma Blog on Sep 12th 2015

How To Run An Effective Meeting

How To Run An Effective Meeting