Ever had a manager who is an "Agile" leader, yet many of things that they do are anti-Agile? Like not including iteration reviews and/or retros? Like going through the motions of populating a backlog, sprint planning and assigning story points, but then not measure velocity, groom the backlog or follow general sprint principles? What is your experience? Saving Changes...
Again there is this confusion between Agile and Scrum but if we are talking about Scrum what I've seen is that it simply does not work as designed for most companies and projects.
If the Scrum framework had really worked as designed it would have been embraced as designed. For most companies Scrum simply does not work and since they don't want to admit this they keep the framework but they don't really do what the framework says it has to be done. That's why you get this situation in which the "Agile Manager" does not do those things.
Why is not Scrum really working as designed? It is either because it is hard to implement and the companies don't struggle enough or simply it does not fit the needs of the business and some things are simply useless overheads. Companies in the end just keep what they think it is useful.
...
1 reply by Stelian ROMAN
Mar 17, 2019 5:32 AM
Stelian ROMAN
...
@adrian, apart from the confusion between Scrum and Agile, understandable when almost 80% of the Agile team, use or pretend to use Scrum, there is also a lack of understanding what Scrum framework is. I seriously doubt that even 50% of those that respond Scrum when asked what they do read the Scrum Guide. First sign is the mentioning of User Stories, which has nothing to do with Scrum. Scrum has backlog Items. Another sign is the use of Story Points for "sizing" user stories. Scrum works, at lest for software development teams but is not as easy to implement as you learn in a training course. It requires, passion, knowledge and commitment. More than anything else it needs trust between the team members.
Unfortunately in many instances the "Agile Manager" is ashamed or afraid to admit failure and at some point someone higher decides to revert to previous approach. That's a shame because not only that Scrum/Agile gets a bad reputation but it will be a missed improvement opportunity..
Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Mar 17, 2019 4:56 AM
Replying to Adrian Carlogea
...
Again there is this confusion between Agile and Scrum but if we are talking about Scrum what I've seen is that it simply does not work as designed for most companies and projects.
If the Scrum framework had really worked as designed it would have been embraced as designed. For most companies Scrum simply does not work and since they don't want to admit this they keep the framework but they don't really do what the framework says it has to be done. That's why you get this situation in which the "Agile Manager" does not do those things.
Why is not Scrum really working as designed? It is either because it is hard to implement and the companies don't struggle enough or simply it does not fit the needs of the business and some things are simply useless overheads. Companies in the end just keep what they think it is useful.
@adrian, apart from the confusion between Scrum and Agile, understandable when almost 80% of the Agile team, use or pretend to use Scrum, there is also a lack of understanding what Scrum framework is. I seriously doubt that even 50% of those that respond Scrum when asked what they do read the Scrum Guide. First sign is the mentioning of User Stories, which has nothing to do with Scrum. Scrum has backlog Items. Another sign is the use of Story Points for "sizing" user stories. Scrum works, at lest for software development teams but is not as easy to implement as you learn in a training course. It requires, passion, knowledge and commitment. More than anything else it needs trust between the team members.
Unfortunately in many instances the "Agile Manager" is ashamed or afraid to admit failure and at some point someone higher decides to revert to previous approach. That's a shame because not only that Scrum/Agile gets a bad reputation but it will be a missed improvement opportunity.. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Mar 17, 2019 12:58 AM
Replying to Sante Delle-Vergini, PhD
...
Hard for someone to see the need for coaching when they see themselves as an expert in Agile frameworks.
Still sounds like coaching is needed. Expert certainly is subjective, and fleeting at best. Regardless, Agile is not story points, stand-ups, refinement (let's use that term and not grooming please, for you know, obvious reasons), planning, etc. Those are scrum related activities. Even so, what does the manager have to do with those activities anyway? If it is Scrum that has been or is being, implemented, then there would be a Scrum Team to focus on the activities you highlighted, not this one person. Potentially, then, the issue lies with the organization or immaturity of not having the scrum team established yet.
...
1 reply by Sante Delle-Vergini, PhD
Mar 19, 2019 12:44 AM
Sante Delle-Vergini, PhD
...
I agree they need coaching Andrew :-)
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Mar 17, 2019 1:01 AM
Replying to Sante Delle-Vergini, PhD
...
Fair point Sergio, but when you have instituted an organization-wide Agile framework (ie. SAFe), broadcast to your customers about the benefits of that framework, and then don't follow many of the things that make that framework successful, then the processes within that framework do become important. Otherwise why institute the framework at all.
I am in charge of that right now. SAFe is a framework then the next step to do after the organization decide to use SAFe is to decide how to fill it up with the best tools and practices in accordance to organizational current situation. That is what you have to talking about, not the framework. People will use tools and practices then you have to sell and implement new behavior and way of thinking not the framework itself. Nothing in Scrum said that you have to use user stories, story points, etc. Nothing, there is not line about that inside the Scrum Guide.
...
1 reply by Sante Delle-Vergini, PhD
Mar 19, 2019 12:50 AM
Sante Delle-Vergini, PhD
...
True, but then the authors of the Scrum Guide have posted 1000's of comments, written 100's of articles, authored several books, and produced numerous Scrum certifications that include knowledge and utilization of these processes and tools. Never forget the caveat on "Individuals and interactions over processes and tools", that being "...while there is value in the items on the right, we value the items on the left more." That doesn't preclude the items on the right. These processes and very much in use, and provide value, if they are done correctly.
Cargo cult and doing agile are just two outcomes of a lack of behavior and mindset shift. A Theory X manager pretending to be agile will likely hurt a team worse than if they were open and honest about their views.
Kiron
...
1 reply by Sante Delle-Vergini, PhD
Mar 19, 2019 12:51 AM
Sante Delle-Vergini, PhD
...
Yes Kiron, my example (and it's a recent one) involved an X Manager dressed in Y clothing.
Yes, and it reminds me of my early engineering college days when I tried to tutor non-engineering students in basic physics...
Engineering physics was calculus based and with a little bit of fundamental understanding of a problem and a gram of math I could derive any formula needed. Other studies used algebra based physics where you had a ton of formulas to memorize and figure out which to apply in which situation. It became very frustrating to me because while I could show the students how to solve entire classes of problems very easily, they wanted a dogmatic cook book approach, rather than understanding the problem and applying some basic theory. Each new problem became an exercise of which formula to apply.
I see some managers trying to apply agile methods in the same way. They don't want to understand what they're doing and instead want a cook book to prescribe to them the exact recipe. I've seen people come back from a weekend seminar convinced we must change the organization to exactly what they learned in their 2 day primer or all is lost.
To me, these people have memorized all of the formulas, but they have internalized none of the fundamental theory. Their "agile" is little more than dogma, and when a new problem comes along that doesn't fit the formulas, they're lost.
...
1 reply by Sante Delle-Vergini, PhD
Mar 19, 2019 12:52 AM
Sante Delle-Vergini, PhD
...
Spot on Keith.
Saving Changes...
Joshua RenderProduct Owner| CognizantHarrisville, Ny, United States
Mar 16, 2019 9:28 PM
Replying to Sergio Luis Conte
...
Agile is not about to iterate, retospectives, backlog, sprint planning or story points. Agile is about to put focus on client, quality, value and feedback. All the other things could be used or not a tools and techniques
Agreed,
I think the point of iterations is to help provide that feedback loop to try and get better- although there are other (and sometimes better, in my opinion) ways to do it.
A lot of my early Agile experience revolved around really badly implemented Scrum. What I learned later is that badly implemented Scrum can be better than well implemented Scrum ---
but I wasn't seeing that in my early days. I saw a guy who led the Daily Scrum, called a project manager, focus not on empowering the team but ruling the team with an iron fist - don't you dare make a decision on how to go about your work without him. He didn't follow Scrum or Agile guiding principles. They adopted the fancy Scrum name and threw on same daily meetings that they called a Daily Scrum, the Project Manager led them. There was no talk of improving our work, ourselves or coming together to unite as a team. Instead, it was lots of meetings under the guise of being collaborative but it failed (I actually recently wrote about my average day under that arrangement using real-life examples I encountered - https://agile-mercurial.com/2019/03/16/i-h...ion-developer/. )
Some of the best functioning teams I have been on didn't concern themselves with following a pre-defined process. They might have started with Scrum, and kept some of the Scrum names - but they ADAPTED and became flexible enough to find what works. They realized that sometimes holding a daily standup every day was just stupid. They realized that sometimes an iteration isn't needed or iterations of varying lengths worked better. So it messed up their structured tracking - the primary measure of success is the produced product, not the velocity of production anyway. They asked us what we thought, they expected us to make decisions on how to get our work done. They didn't force us into meetings because they thought we should know a whole bunch of ancillary stuff not relevant to our work.
...
1 reply by Adrian Carlogea
Mar 19, 2019 6:23 PM
Adrian Carlogea
...
" [...] I saw a guy who led the Daily Scrum, called a project manager, focus not on empowering the team but ruling the team with an iron fist - don't you dare make a decision on how to go about your work without him [...]
I think when talking about empowering the team it is very important to specify the type of decisions the team members should be empowered to take.
For instance many software developers only care about the purely technical decisions and simply don't want to be involved in other types of decisions. Of course the non-technical decisions do impact the technical ones and vice-versa but still many technical experts don't like to take non-technical decisions.
That being said many times it is better not to "empower" the team as the team members may not like to be empowered to take decisions they don't want to take.
And of course the degree of technical knowledge the PM/Scrum Master has is crucial when leading the team as a non-technical PM or Scum Master can't really lead the team in an authoritarian way. I mean he will not be able to give any commands to the developers as he would not be able to formulate them.
Only technical leads and technical managers with deep technical knowledge can really lead with an iron fist. Non-technical managers trying to lead with an iron fist would just look like clowns and the team members would make fun of them and of their lack of knowledge.
Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
Mar 16, 2019 10:03 PM
Replying to Stelian ROMAN
...
Sante, not only managers but I know many coaches that pretend to be Agile but they do it as a PR exercise rather than implementing Agile values and principles. I've seen many "Agile" implementations that ale limited to picking low hanging fruits like stand-up, kanban board and assigning story points, that no-one has any idea how to estimate. The sad thing is that most of those "Agile experts" didn't even read the Scrum Guide. There are no user stories and story points in Scrum.
POs that don't take any decision nor remove impediments, Scrum Masters that focus on weekly reporting and Jira/Confluence administration are pretty common.
Stelian, great comment! I have seen examples of "Agile" coaches who ride in like a bull in a china shop, causing a great deal of damage to the organizations they visit without helping them become more agile.
To be fair, I've probably witnessed even more organizations that hire consultants to help with their "agile transformation," which have no desire to change. They spend a great deal of money to create an Agile façade on the front of their organization, but they resist any meaningful change. Saving Changes...
Very interesting topic, following from ‘quite a distance’, reassuring insights to real life case from Joshua, thank you all! My takeaway on that diary, “You are a programmer, you have mastered the art of sleeping with your eyes open.” simply classic :-) Saving Changes...
