Skip to main content

Rough notes: Misunderstood agile practices

Let us assume management and team have some experience with agile but they only understand parts of it (such as iterative delivery, sprint ceremonies etc.). Have you faced such situations? Which practice(s) and concept(s) did you strive to adopt but were challenged? what tools did you use for influencing the outcomes?
 


Here are some highlights from a LinkedIn discussion I started about misunderstood agile practices.

* In many "traditional" companies agile is seen as a new set of controls to get work done. Old roles are re-labeled.

* Many companies think that they can purchase agile as product also if they have few certified SM/PO on pay roll, company is agile.

* Misconception: Equating testing with quality improvement. Quality needs to be designed in from the get go.

* Try this: Making metrics visible. Nobody can argue with truths, and the truth is a strong motivator of change in group dynamics.

* Conducting honest retrospectives over many sprints is often neglected.

* The biggest mistake that people make is thinking that Agile is a process, and if you do the process, you'll be successful.

* Agile practices could be perfectly implemented but with inappropriate mindset and intention, then practices perfectly implemented in physical and visible shapes will all always be misunderstood.

* Misunderstanding Being Agile vs. Doing Agile: Most people don’t understand the difference between Being and Doing. Agile isn’t something you do. It’s something you are.

* Misunderstanding the proper amount of documentation needed. Reading "Working software over Documentation and Processes" and forgetting the final line of the manifesto, "Although we value the things on the right, we value the things on the left more".

* The problem is with the mindset. A mindset change is more difficult of a change and involves coaching/training/teaching and importantly discussions around what Agile is to the team/department/company.

* Many chickens do not understand the "doing" vs "being" agile.

* Misunderstanding: Many organizations associate agile with tools...like "I am using Jira / Rally / TFS /(any other tool you can think of) and still not able to get the benefits of agile. Looks like agile doesn't work for us"!!!!

* Transparency does not mean micromanagement.

* Misunderstanding: Dysfunctional Waterfall is the same as Successful Waterfall.

* Misunderstanding: If I cut my big traditional programme of x years without any reliable progress indicator into small iterations, that I can reasonable expect precise forecasts / commitments and then still get all the benefits of agile.

* Misunderstanding: Agile methodology is not suitable for products which take multiple years to build.

* Misconception: "Agile is for those who are not disciplined enough for processes", i.e. "You can improve Agile by introducing more rigid processes."

* Try this: Look at your dev / test / staging infrastructure and automation around that. And your engineering skills and practices.

* Misunderstanding: Scrum ceremonies often misunderstood and poorly done, but yes Daily Standup especially. As it returns every day.

* Misunderstanding: "We create user stories ñ try to complete them in two weeks" so we follow agile ...

* Misunderstandings: Originally, there are things like "I can't break down my work that small." Or "our testers are used to being at the end, we can't include them in our current sprints." And the misconceptions just move on down the line as you transform the teams.

* Quote: Wisdom begins when we discover the difference between "That makes no sense" and "I don't understand". --Mary Doria Russell

* My favorite takeaway: It is far better to move ahead with a wealth of misconceptions and the personal and organizational intent to continuously improve than to try and identify and correct the misconceptions first.

Comments

Popular posts from this blog

14 Essential Software Engineering Concepts for Engineers and Managers

There are many terms and concepts that are important for an engineer to be familiar with, in order to effectively build software. This post includes some of those terms. I will continually add to or update this list. Agile. A flexible and iterative approach to software development that emphasizes collaboration, customer feedback, and adaptive planning. My experience and success with agile development was the inspiration behind starting this blog. DevOps. A set of practices and tools that improve efficiency, speed, and reliability of the product through automation and optimization of the software development and delivery process where operational efficiency is part of the development process. Continuous Integration and Continuous Delivery/Deployment (CI/CD). A set of practices and tools that result in faster and more frequent releases, through automation of building, testing, and deployment of software. A key part of CI/CD is to deliver software to production frequently and using tec...

Forget Onboarding, do Alongboarding!

Alongboarding, an agile onboarding approach Alongboarding: We’re in it together! Organizations hire new people every day. A great first impression can make a tremendous difference in retaining employees. No one gets a second chance to make a great first impression, not even the best companies. An onboarding experience is an essential part of making that first impression on a new employee. Agile has been around for many years and has gained vast acceptance throughout the community. Yet, I find it disappointing that its tenets are not used well in most companies and most onboarding approaches follow a waterfall approach.  Alongboarding is an agile onboarding approach that applies agile tenets to onboarding new employees and makes the experience richer and more fulfilling. When I joined AppFolio as an agile coach, I experienced this approach during my onboarding. It felt like the team owned my success as much as I owned the team's success. It was a welcome change from some of m...

Make onboarding fun with Onboarding Canvas!

The Onboarding Canvas is a tool that can be used for onboarding a new team member . We derived this tool from Spotify's adaptation of the Toyota Kata . I like this tool because no one can tell you precisely how your onboarding should be like in order for you to be effective at your new job. This is a tool for continuous reflection and adaptation. It puts the newcomer in the driver’s seat, makes the onboarding process agile through continuous collaboration with your team. Four quadrants The onboarding canvas has four quadrants: Now: It defines where the team is now, what is going on and how is the new team member adapting to the change? Definition of awesome: With the addition of the new team member, how would the team like itself to be? What would be awesome for the new team member? Next target: In order to move towards "Definition of awesome" what outcomes should be achieved in the next x weeks? Next steps: What are the immediate next steps for the team...