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 

An Agilist Needs More Than Training To Succeed

#SridharPeddisetty #Agile #Scrum #Strategy #Organizational Strategy #AgileTraining #AgileBestPractices

After his return from Rome, Will couldn’t find his luggage in the airport baggage area. He went to the lost luggage office and told the woman there that his bags hadn’t shown up on the carousel. She smiled and told him not to worry because they were trained professionals and he was in good hands. Then she asked Will, “Has your plane arrived yet?”

The most essential part of Agile transformation besides the Org. change champion, is proper training and in this post the intent is not to undermine the importance of training. Agile based trainings or certifications provide you possibly the knowledge about Agile but not necessarily the wisdom needed to apply it successfully. Implementing Agile in any Organization requires more than just knowing the terms or ceremonies. It requires changing the mindset of people and working on making changes to the legacy processes and tools.
In my experience, most of the trainings do not cover on what exactly Agile Manifesto meant by uncovering better ways of developing software. So here is my attempt of dissecting what is included in the Manifesto. 

• Individuals and interactions over processes and tools - You need to develop a self performing team that owns collective responsibility but then for them to be successful, communication has to be transparent. You cannot be a ‘self performing’ team without bringing in the transparency using processes and tools. Scrum ceremonies (Sprint planning, Daily Scrum, Sprint Review & Sprint Retrospection) provides you the discipline to be transparent but we need to ensure that the transparency in communication & collective responsibility is flowing across the Organization. In my earlier post Trust your Team But Make Sure to Verify, I had shared that trusting your self performing team is important but its essential to verify that team is performing to its optimal level as a unit and not showing just individual brilliances, which can be counter productive for the end results.

• Working software over comprehensive documentation - In order to develop a ‘working software’, project team and stakeholders should have ashared understanding of the project objectives or goals. We do not need to spend a lot of effort to create an accurate or comprehensive project charter but what we need is a good understanding of the vision, which is shared. Agile based SDLC of building potentially shippable products incrementally in short periods of time is one of the most tangible changes and benefits, which an Agile process provides. But again, its important to remain focused on the shared vision. Have enough documentation to serve the architecture, design, delivery, user acceptance and deployment of a working product in short iterative/incremental cycles. 

• Customer collaboration over contract negotiation - In my earlier post Minimum Marketable Features: An Agile Essential, I had shared that Organizations no longer compete on product or service but they compete on experience of faster to market with quality results. It is an organization's ability to learn and translate that learning into action rapidly, which gives it the ultimate competitive advantage. Traditionally, the negotiations with customer were happening upfront at the start of a project with more energy spent on trying to be safe in terms of scope of work, cost & schedule. With a practical Agile approach, a trusting collaboration can be fostered between the customer and project team in which discovery, questioning, learning and adjusting with shorter feedback loops during the course of the project will have a better chance of delivering a product, which provides the customer with a competitive advantage than a contract that is signed early in the lifecycle and is difficult to change.

• Responding to change over following a plan - Planning is important because if you don’t know where you are heading, any road would take you there. But having said that, experience has taught us well that creating elaborate project plans does not guarantee success of a project. Also we understand that in this disruptive era, its not pragmatic to freeze product requirements, priorities and timelines. Change is the only constant factor in a SDLC and we should plan enough to be receptive to change. Agile creates an opportunity for increased customer satisfaction and return on investment by handling change effectively with more robust feedback loops, which accommodates changing requirements to generate higher-value products. Bottom line is to plan continually rather than plan once and follow it to the core. 

Summary

To summarize, getting trained in Agile does not necessarily mean that we have started thinking ‘Agile’. After training, 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. 

If you want something talked about, ask a theorist and if you want something done, ask a practitioner!

Previous posts you might be interested in

• Minimum Marketable Features: An Agile Essential
• Looking At An Impediment From A Value Perspective
• 5 Tips Delivering Quality Services To Your Client

DevOps Is Essential For Faster To Market Services

#SridharPeddisetty #DevOps #Kanban #Strategy #Organizational Strategy #DevOpsStrategy #Agile

“If you can’t out-experiment and beat your competitors in time to market and agility, you are sunk. Features are always a gamble. If you’re lucky, ten percent will get the desired benefits. So the faster you can get those features to market and test them, the better off you’ll be. Incidentally, you also pay back the business faster for the use of capital, which means the business starts making money faster, too.” 

― Gene Kim, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

It is no longer enough for organizations to merely build and release a better product to stay ahead of competition but in today’s disruptive era, the need of the hour is to build and ship faster than everyone else. In order to meet the demands of time to market features, organizations have realized the necessity to be Agile and are having a paradigm shift in the way they build and ship software. Agile SDLC with continuous integration and rapid deployment have now become a de-facto standard. In my earlier post Kanban & DevOps - Forming A Perfect Alliance, I had shared how Kanban and DevOps combine together to help bring down the silos between Engineering and Operations teams. 

Former Cisco CEO, John Chambers in his last keynote strongly put it forward that 1/3rd of today’s businesses would not survive next 10 years. Startup companies are already disrupting long established business models and they are succeeding mainly because of their ability to faster to market services. 

How DevOps Is Essential For Faster To Market Services?

DevOps formulates collaboration of Operations and Engineering teams to achieve continuous delivery by participating together in the entire service delivery lifecycle. In my earlier post DevOps Need Collaboration To Succeed As A Practice, I had shared how by adapting to the culture of DevOps, an organization is not only focusing on agility but also on reliability by eliminating waste, identifying repeatable steps and automating those steps. DevOps is not just about technology disruption but is about transformative Organization and its ability to deliver value to the end consumer. Technology has become core for most businesses and is now an essential for their survival in a highly competitive space. Large enterprises have to be more nimble and the need of the hour is to move away from their large & complex interrelated legacy systems to a more Agile based environment with DevOps fueling the collaboration delivery setup.  

Summary

Early adopters of DevOps have seen a significant increase in their revenue, faster time-to-market and improved customer experience with their success depending on their ability to deliver a continuous flow of value from APIs, new mobile apps and software innovations.

Previous posts you might be interested in

• Kanban & DevOps - Forming A Perfect Alliance
• Minimum Marketable Features: An Agile Essential
• DevOps Need Collaboration To Succeed As A Practice

DevOps Need Collaboration To Succeed As A Practice

#SridharPeddisetty #DevOps #Kanban #Culture #Collaboration #SchneiderCultureModel #DevOpsStrategy #Agile 

“A great team doesn’t mean that they had the smartest people. What made those teams great is that everyone trusted one another. It can be a powerful thing when that magic dynamic exists.” ― Gene Kim, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

DevOps formulates collaboration of Operations and Engineering teams to achieve continuous delivery by participating together in the entire service delivery lifecycle. DevOps is NOT a role but it is a shift in culture of an organization, which encourages greater communication and collaboration to foster building better quality software more quickly and with better reliability. There are good number of people who agree that DevOps is not a new phenomena and some organizations have been formulating collaboration of Operations and Engineering teams to achieve continuous delivery by participating together for releasing new product or service. However there are good number of organizations who are either warming up to the idea of DevOps and ready to adopt it or going through initial phase of DevOps adoption. It is important for the organizations to understand that "collaboration culture” is key for them to successfully adapt to DevOps. In my earlier post Kanban & DevOps - Forming A Perfect Alliance, I shared how Kanban and DevOps combine together to help bring down the silos between Engineering and Operations teams. 

Why DevOps need collaboration to succeed?

To understand why DevOps need collaboration to succeed, let's understand Schneider Culture Model, which defines four distinct cultures:

1. Collaboration culture is about working together
2. Control culture is about getting and keeping control
3. Competence culture is about being the best
4. Cultivation culture is about learning and growing with a sense of purpose

In the diagram below, Michael Sahota shared his thoughts on understanding the culture of an organization using Schneider Culture Model. Each of the four cultures are depicted – one in each quadrant with each having a name, descriptive quote, a picture, and some words that characterize that quadrant. 

As can be seen in the diagram, collaboration quadrant includes the words affiliation, synergy, partnership, interaction, trust, diversity and egalitarian to characterize itself while the descriptive quote is “we succeed by working together”. These are the exact characteristics that are needed for DevOps to succeed as a practice in an Organization in which Engineering and Operations teams come together to work with affiliation, synergy, trust as partners by closely interacting with egalitarian philosophy. 

Note that according to Schneider model, no one culture type is considered better than another and same is applicable to DevOps, in which possibly cultural elements from other quadrants (control, cultivation and competence) are applicable to DevOps. Depending on the organization but for DevOps to succeed, definitely the organization needs to have ‘Collaboration’ as the single dominant culture with elements from the other three culture quadrants.

By adapting to the culture of DevOps, an organization is not only focusing on agility but also on reliability by eliminating waste, identifying repeatable steps and automating those steps. Organizations will fail in adapting DevOps if the culture is not breaking down the organizational silos and in which everyone shares the accountability for delivery.

Summary

DevOps represents both a technology and a culture change in the organization and the objective of DevOps can be achieved only if the culture of the organization is more collaborative. In other words, DevOps need more of a "collaboration culture” in the organization to succeed as a practice. 

In the comments section, please share your thoughts on what do you think an Organization must do for DevOps to succeed and make a positive impact. 

Previous posts you might be interested in

• Kanban & DevOps - Forming A Perfect Alliance
• Value Stream Mapping As A Process Improvement Tool
• Metrics For Maximizing Productivity In Kanban SDLC

Value Stream Mapping As A Process Improvement Tool

#SridharPeddisetty #Agile #PMO #ValueStreamMapping #Lean #Kanban #Value #Stream #Mapping #BestPractices #ProcessImprovement  

“If you can't describe what you are doing as a process, you don't know what you are doing” 
― W. Edwards Deming

What is Value Stream Mapping?

Value Stream Mapping is a lean tool, which employs a flow diagram documenting in detail every step of a process. It is the fundamental tool to identify waste, reduce process cycle times, and implement process improvement.

Why use Value Stream Mapping?

Organizations no longer compete on product or service but they compete on experience of faster to market with quality results. In order to enable Organizations to achieve their strategic objectives, continuous improvement of the quality of products, services or processes must be ongoing. Value Stream Mappings help identify and eliminate source of waste in an Organization's development ecosystem. It is an invaluable technique to define the current state of a process and analyze it for opportunities to reduce time spent on non-value steps. 

How to use Value Stream Mapping?

Below is an example of how Value Stream Mapping was employed for identifying the wastes in current ‘As Is Process’ and then eliminating the wastes for improving the overall process in ’To Be Process’. 

In the Figure: ‘As Is’ Process, wastes in the process are marked by a triangle identifying where tasks are taking too long either by redundancy or following unecessary steps. Value Stream Mapping provides an opportunity to identify steps in the process, which provides value to the development process and those that do not. 

                                                        Figure: 'As Is’ Process

In the Figure: ‘To Be’ Process, wastes are eliminated and Value Stream Mapping is applied to create a future state process that reduces total cycle time

                                                      Figure: ‘To Be’ Process

Summary

Apply the method of Value Stream Mapping to an inefficient process within your organization and learn how to calculate the efficiency of a process from end-to-end. Learn to diagram the 'As Is' process to identify areas of waste and then develop the 'To Be' process that reduces total cycle time. An organization's ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage and Value Stream Mapping is the tool for providing that efficiency in process improvement. 

"Without continual growth and progress, such words as improvement, achievement, and success have no meaning"- Benjamin Franklin

Value Stream Mapping As A Process Improvement Tool was originally posted under Prokarma Blog on Oct 5th 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