Effective Coaching Model for Agile teams
There is a world of difference between the management principles in the era of the Industrial revolution to the current world of information revolution. We need to acknowledge the increasing gap between the way employees are being managed at work, and the way they want to be managed. Many surveys have been done in this area, ending in headlines like “6 out of 10 employees are miserable” and “74 percent of staff not engaged at work.” Dig into these surveys and you’ll see the quality of leadership on top of the list of complaints. The poor state of leadership and management skills in organizations is being driven by a broad range of factors, including but not limited to
The changed nature of work - More of skill and innovation
The increasing education of employees - Continuous improvement and learning needs
The needs of later generations - The more sofisticated needs of the system
The pace of change - The quick pace of changes
In the current “rat race”, the management focusses on higher productivity and higher ROI, but they lack the capacity to “motivate” their employees that can take them to the next level of thinking. The "leaders" do not understand the subtle difference between teaching, mentoring and coaching. They use these words interchangeably without realizing that coaching teams can help them to increase the productivity, morale and create great employees resulting in more successful products.
A new coaching model is required to enable continous improvement with quick feedback cycles that fosters adaptability and innovation.
Two relevant quotes which I can relate to this issue are
"It is people who build organizations and not organizations who make people" - unknown
"Beware of little expenses; a small leak will sink a great ship" - Benjamin Franklin
Outline/structure of the Session
- 5 min - Introduction
- 5 min –Context setting
- 5 min – Difference between Teaching, mentoring and Coaching
- 10 min – Secret sauce of motivation
- 5 min – Existing models and the challenge in these models
- 10 min – 3D, 4E model of motivation
- 10 min – Case study
- 10 min Q&A
- Understand the art of coaching and art of being a coach
- The secret of the real motivation
- The new coaching model
- Case study
Project Managers, Agile Coaches, Program Manager, Scrum Masters, teams
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Happy Teams are key to successful agile transformation– Teams’ self-designNanda Lankalapalli
schedule 2 years agoSold Out!
Agile Teams' self-design is very important (though not very common) exercise in a large-scale agile transformation. In teams’ self design, team members choose their own teams in a collaborative way. This concept here is that the teams will gel quickly and excel when they are self-designed.
In this session I am going to present my experience with such exercise. I facilitated at least 4 such sessions to help an organization as part of a large-scale transformation. The session is going to explain
- Benefits of Feature teams over Component teams
- Self-design of feature teams
- Pilot exercise of self-design of 2 feature teams.
- Large scale self-design of 4 product groups with 30 to 50 members per group.
Implementing Agile Engineering Practices in Legacy Codebases
Afraid of legacy code? Don't be!!!
Most successful product companies are confronted with the problem of legacy code.
What is a legacy code?
- A code which is in production for several years.
- A super-complex, hard to understand code base, written by different set of developers.
- Outdated Technology stack.
But the most hurting reality is:
Lack of confidence in the code due to zero or poor test coverage.
Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."
Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.
As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.
One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little.
Today we all know this is a BAD option!!!
Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.
How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.
What do we do?
Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:
- Re-structuring the Project code-base
- Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
- Creating/fixing the build script
- Setting up an auto DB deploy tool and integrating it with build scripts
- Set up basic CI pipeline
- Write a few work-flow tests to capture the system's flow from user's point of view
- Find the inception point in the code from where we can exercise the code
- Restify the application at the inception point (one service at a time)
- Setup authorization for production and test environment
- Build minimal test-data set for different environment
- Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
- Write business logic acceptance test to capture various complicated business rules
- Test drive the new enhancement or bug fixes
- Every time we touch legacy code, refactor the code and improve test coverage at unit level
This really helped us test driven the new code and implement all the layers of the test pyramid.
If you've a similar situation, join us, as we share our experience on how to confront legacy code.
Death of Inspection: Reincarnation of the Testing Community
Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.
This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.
We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.
Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.
Deep dive into RETROSPECTIVES- how do we break the usual norms so that these reflections could be made thought-provoking ones!
Retrospectives are the primary learning, reflection and readjustment techniques on agile projects. A good Agile team is always striving to become better than before. And an effective retrospective enables the team to sieze its opportunity to improve!
Retrospectives enable whole-team learning, act as catalysts for change, and generate action.
R-> Realize where you are and where you want to be
E-> Engage the teams in fruitful discussions
T-> Team work to build “We over I” attitude
R-> Relish the power of Inspect and Adapt cycles
O->Openness and Transparency to make retrospectives efficient and effective
In my view, this is not any new concept or a jargon the team needs to really master, but yes in reality sometimes it becomes challenging to keep the momentum lively all times! Over a period of time, we see these symptoms in a retrospective.
R-> Repeated issues pop-up
E-> Engrossing & Engaging discussions are missing
T-> Team present virtually, loses trust.
R-> Routine stuff, nothing interests the teams.
O->Observably gets boring over time.
To catalyse conversations among team members, retrospectives need to be viewed from a different perspective. This presentaion talks about why the retrospectives efficacy fades off over a period of time and then talks about some very interesting techniques that I used with the teams to make these meetings lively! Teams need to do out-of-box thinking and appreciate that these short gatherings need not be done only by using the techniques or methods prescribed in the book but could be done by quoting some situational specific examples that would make the teams really think and speak!
Techniques to Speed Up your Build Pipeline for Faster Feedback.
We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.
Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.
Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.
Techniques for Effectively Slicing User StoriesNaresh Jain
schedule 2 years agoSold Out!
In order to achieve my goals, as a buyer of your product, I want awesome feature.
AT: make sure your users stories don't get in the way.
Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.
Big AgileSriram Narayan
schedule 2 years agoSold Out!
Good engineering practices and fail-fast, iterative, low-ceremony processes help achieve team level agility. They are necessary but not sufficient to scale agility across the IT organization. In this talk, I'll address what else is needed and why. In particular, I'll address:
- Why plan-driven IT projects are a bad idea why we need value-driven projects instead
- Why a matrix org is a bad idea for IT and why we need cross-functional teams instead
- Why IT budgeting needs to change from being project-based to being team-capacity based
Scaling Agile in a Mainframe Product Development Organization
Agile transformation in any organization will go through myriad of challenges that involves people, existing organization culture, technology/domain etc. Instead of seeing these challenges as obstacles, if you view them as opportunities to grow and improve, transformation will be more impactful and long-lasting. If neglected, the very same obstacles would severely damage the motivation and trust of employees.
In this experience report we would like to walk you through the agile transformation journey in a Mainframe product development enterprise by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. Specifically we would like to touch upon
- Self-organizing teams
- Resistance to change
- Culture shift
- Lack of role clarity and
- Effective R&R in agile space
- Agile Engineering Practices adopted in Mainframe product development
- Unit test automation
- Continuous Integration
Along the presentation we’ll highlight few anti-patterns and the effects of ignoring them.
Gamifying Agile Adoption - An Experiment
While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?
For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention, from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.
The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.
- Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker".
- We have now added more badges to recognize individual efforts in various categories.
- Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar
Navigating the "Scaling Agile" landscapeYuval Yeret
schedule 2 years agoSold Out!
Scaling Agile is the hot trend these days. There are various options people are currently using to scale agile across their organization ranging from the trendy SAFe through the evolutionary Kanban all the way to classic LeSS. As an enterprise agile coach with straddling both the Kanban and SAFe worlds with experience helping various global enterprises to be more agile at scale I have a wide perspective of the agile scaling approaches landscape which I will share in this session. Together we will look at the various leading approaches to Scaling and understand how they compare, where each is appropriate, how to mix and match them. We will also spend some time discussing change management/implementation aspects of using the the various approaches and how to move through the selection, kickoff, stabilization and recharge phases and ideally move to improve mode at some point.
Gamified Simulation: Learning mechanism to be an impactful Scrum Master
We represent the Agile Center of Excellence at our organization and are chartered to drive the change management initiative to imbibe Agile adoption across the enterprise.
We realized that while the external Scrum Master Certification trainings or our internal certification training would help ingrain the knowledge of a Scrum Master; However we found it extremely crucial that there needs to be some mechanism to ensure the candidates should understand the on ground situations/challenges and various behavioral scenarios that they would face wherein they need to take certain decision accordingly.
We used the gamification concept to capture our past experiences in various engagements wherein we had encountered multiple situations/challenges faced by the Scrum Masters. This would help the newly onboarded trained Scrum Master to improve upon their decision making thought process. The concept would also have a scoring mechanism which would give them chance to improve upon their existing competency.
The gamification would focus on:
- Problem solving in the given situation
- Facilitation skills
- Process Concepts
- Stakeholder relationship
- Building high performance teams
- Building Early warning system
Will Scrum alone create miracles! Or does it need some best buddies…..Let us understand through a real team story!Madhavi Ledalla
schedule 2 years agoSold Out!
Summary of the presentation :
Scrum is a framework. It just suggests some good practices which are like guidelines similar to the good-to-do things. These practices keep the system moving and are like driving directions that enable us to have a healthy rhythm. Now how is this rhythm of scrum affected by the behavioural ecosystem? The blend of people right from the top management to ground level get affected by this adoption of Scrum and also influence the scrum adoption to a greater extent. This adoption is a journey, and Scrum aids in making this entire journey enjoyable and valuable, of course we need to add some ingredients and some spice to it to make this adoption journey valuable and fun-filled. So in this presentation we would talk about the powerful roles in Scrum and most importantly how to make the environment around it suitable to have a smooth ride.
This case study is created based on a real journey of the team and the team is still continuing their scrum journey.
This case study highlights the following.
Project Kick off
Role of organization top-management in this journey?
How to handle the most important resource-“PEOPLE” in the Scrum journey?
Some effective ways to clean up the chaos that scrum exposes?
Learn what are the key ingredients of Scrum?
How do we spice it up to make the ride a fruitful happy ride?
Some creative and innovative ways to make the ride a fun and valuable ride!
How can the master chef, the Scrum Master make this journey a success?
How to churn the teams to become great teams!
PS: I can submit a detailed report based on which the slide deck is created to the reviewers. Thank you.
Agile adoption journey is very challenging and expensive but yet would yield great results if we do it in a proper phased manner with good planning and insight. Scrum, one of the agile methodologies, helps the projects to cater to the dynamics of changing market while delivering high quality software when combined with few engineering practices.
True! Let us try to understand the ground realities of scrum and then see how its adoption gets effected by the surrounding ecosystems and environment using simple metaphors and then let us take a deep dive into the depth of the realities. Scrum is like a powerful filtration process that allows the filtrate to pass through smoothly while exposing the residues which are the real bottlenecks, impediments, road blocks in a transparent manner. Once these residues are cleared, crystal clear increments of working software could be seen by the Stakeholders. So it is up to the environment around Scrum to act on the realities that Scrum exposes and clear it up as early as possible so that the working software could be delivered faster. If we do not react to these impediments that Scrum exposes, we would be where we were earlier and nothing might get changed!
Successful implementation of Scrum would need the key ingredients, which are the robust engineering practices like Continuous integration, Daily Builds, Automated build process, Build notifications, Continuous Deployment and Delivery in place to deliver quality software.
We need to enable and empower the most important resource, “PEOPLE” very carefully all through the journey so that they do not get over churned and break half-way through the ride. We need to add just enough lubricant to make the team vehicle move smoothly. Organization plays a vital role in giving the necessary push as and when required by providing the essential support in terms of the infrastructure and other requirements that would aid the Scrum journey. People who have a positive attitude and who are willing to work with the team on the ground would sustain this adoption process. People who try to create roadblocks along the journey should be handled with care skilfully.
Now to make the journey really a fun-filled ride, definitely some spice in the form of creativity and innovation is needed to produce the flavor to make scrum tour amazing and an exciting journey that churns good teams to great teams. The three roles of Scrum, the Product Owner, the Scrum Master and Development team should synchronize well with each other to succeed. Most important role in Scrum, the master chef i.e the Scrum Master keeps the Scrum team intact by ensuring that all the ingredients and spices are in proper ratio. The Scrum Master is the magic wand behind the scenes that can enable things really happen.
The above points would be revelead by going through the journey of a scrum team that I worked with.