Order or Agility, or Both?

 

I work in Information Technology at a large company. We, like many companies around the world, are aggressively adopting Agile techniques to build and support software applications within the company. The basic principles of Agile are outlined in The Manifesto for Agile Software Development, developed in 2001 by a group of software developers who had been practicing the techniques for many years. Agile and Agile Transformation is one of the hottest management transformation fads right now (think back to Business Process Re-engineering or Strategic Sourcing which were the big ones in the 1990s).

This being a fad, the term “Agile” gets used to mean many things. There are many methodologies with their owners and proponents. These include Scrum, Extreme Programming, Kanban, SAFE, LeSS, etc. I will try to explain what I understand Agile to be in principle and stay away from the specifics of the various methodologies.

Agile is based on the principle that you get better results and value from small dedicated teams working on small increments of work that are quickly deployed to production for use by the customer. The team works with customers and defines a backlog of features for the application or product. The key stakeholder in the product, often called the Product Owner, sets the priority of each item in the backlog. The team then decides what features will be taken from the backlog for the next iteration of product development. The team manages itself and has all the skills and tools to deliver working code in production. Ideally, line management is spread thin and focused on eliminating blockers outside the team and obtaining the resources the team needs.

In one version of larger-scale Agile, LeSS or Large-Scale Scrum, they advocate no budgets, no projects, no programs, no project or program managers, even no managers. The team and the product owner maintain a longer-term roadmap, but that is continually revised at each iteration as feedback from new features being introduced changes priorities – new things are learned so the roadmap changes. Change and adaptation are constants.

Doesn’t sound very orderly, does it?

So why do most software companies and now many IT groups use Agile for development? Let’s talk about what it replaces. Software projects typically followed a waterfall method. You’d start off with high-level requirements which would be the basis for a huge Microsoft Project plan and a detailed budget. Then the team would assemble, with analysts working with customers defining detailed requirements. Once the requirements were complete and signed off, the analysts would write specifications. Programmers would code from the specifications and then testers would test. Finally, after months or years, the end result would be delivered.

This end result was almost always over budget and schedule and did not meet customer expectations. To quote the consulting firm McKinsey from 2012 “On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.” Because these projects are large and complicated, we created the illusion of control through layers of management and a big project plan that was pretty much a work of fiction.

It may seem orderly, but it certainly didn’t produce results in an orderly manner.

The seemingly less-orderly Agile approaches, when properly implemented, deliver far better results. By continuously incorporating feedback, the right things get built. By empowering individuals and teams, things get built right. Much more orderly in the end.

Changing the way an organization works is not easy nor should it be taken lightly. Perhaps the biggest underlying change is one from Theory X management to Theory Y management (from The Human Side of Enterprise, Douglas McGregor 1960). Theory X says people hate work and will try to avoid it and so need to be coerced, controlled, and directed so they will work. People will not take responsibility and want to be directed. Many management practices – performance reviews, individual targets, bonus systems – are based on these Theory X assumptions.

On the contrary, Theory Y assumes that people will work as naturally as they play or rest. They will be self-directed for goals to which they are committed. In the right environment, people seek responsibility and will creatively apply themselves. Agile practices are built on Theory Y assumptions.

Changes the practices and attitudes of people across the organization is difficult. Managers need to give up some control. Executives need to accept a little more uncertainty. People doing the day-to-day work need to believe in and adopt the core Agile practices.

I was a skeptic several years back. Now I am a convert and deeply involved in our transformation. It is a journey, not an event. We are not perfect but are progressing. We are pursuing it in an orderly manner, inspecting and adapting as we go.

(Credit to Large Scale Scrum: More with LeSS, Craig Larman and Bas Vode, 2016 for the management theory discussion)

Published in Group Writing
This post was promoted to the Main Feed by a Ricochet Editor at the recommendation of Ricochet members. Like this post? Want to comment? Join Ricochet’s community of conservatives and be part of the conversation. Join Ricochet for Free.

There are 34 comments.

Become a member to join the conversation. Or sign in if you're already a member.
  1. Phil Turmel Inactive
    Phil Turmel
    @PhilTurmel

    I’m a fan of Agile methods, though I don’t get to apply all of them myself (my projects are solo).  I’m not a fan of large scale scrum or other pure Theory Y ideas, as I don’t think every employee is suited to it.  Someone needs the oversight to identify bad apples and the authority to counsel them or fire them.

    • #1
  2. Clavius Thatcher
    Clavius
    @Clavius

    Phil Turmel (View Comment):

    I’m a fan of Agile methods, though I don’t get to apply all of them myself (my projects are solo). I’m not a fan of large scale scrum or other pure Theory Y ideas, as I don’t think every employee is suited to it. Someone needs the oversight to identify bad apples and the authority to counsel them or fire them.

    The best answer to the issue of bad apples is that they are “blockers” that management should remove. 

    • #2
  3. Judge Mental Member
    Judge Mental
    @JudgeMental

    Phil Turmel (View Comment):

    I’m a fan of Agile methods, though I don’t get to apply all of them myself (my projects are solo). I’m not a fan of large scale scrum or other pure Theory Y ideas, as I don’t think every employee is suited to it. Someone needs the oversight to identify bad apples and the authority to counsel them or fire them.

    My projects were mostly solo, and I thought that made it even easier to do things this way.  I never heard it called Agile until after I’d been doing it for years.  I was just trying to get enhancements deployed as quickly as possible because the customers like it.  If they request a change at noon, and it’s in production the next morning, they like it a lot.

    And bug fixes as well, although of course, there were never any of those in my code.

    • #3
  4. Susan Quinn Contributor
    Susan Quinn
    @SusanQuinn

    I am not an IT person, but even I can see the value in these practices! I do remember the quality teams of the ’90s and they had their ups and downs. But this approach makes sense. And as a little end user, I approve! Thanks @clavius. You explained it well.

    • #4
  5. Clavius Thatcher
    Clavius
    @Clavius

    Judge Mental (View Comment):

    Phil Turmel (View Comment):

    I’m a fan of Agile methods, though I don’t get to apply all of them myself (my projects are solo). I’m not a fan of large scale scrum or other pure Theory Y ideas, as I don’t think every employee is suited to it. Someone needs the oversight to identify bad apples and the authority to counsel them or fire them.

    My projects were mostly solo, and I thought that made it even easier to do things this way. I never heard it called Agile until after I’d been doing it for years. I was just trying to get enhancements deployed as quickly as possible because the customers like it. If they request a change at noon, and it’s in production the next morning, they like it a lot.

    And bug fixes as well, although of course, there were never any of those in my code.

    It does seem natural, but does not have the control, reporting, status updates, etc. that management feels it needs to be in control.

    And not only do customers like getting things quickly, it changes what they ask for.  If it takes six months to get something, you’ll ask for everything you can imagine.  If it’s a couple of weeks, you’ll be more focused on what you really need.

    • #5
  6. WillowSpring Member
    WillowSpring
    @WillowSpring

    Clavius: The key stakeholder in the product, often called the Product Owner, sets the priority of each item in the backlog

    I think this role is one of the most important and one most often ignored.  I worked off and on for a year on a project where the “product owner” (from marketing) was working with continually with my engineering team to add new features to the product – which we produced.  When the time came to to deliver the product, it became clear that the “real” customer’s main interest was the lowest price he could get.

    • #6
  7. Henry Racette Member
    Henry Racette
    @HenryRacette

    I like a lot about agile methodologies, and very much appreciate the philosophy behind it. I like the dynamism of the rapid-cycle develop-deploy-evaluate-revise process, the way it integrates operation and development to solve the most pressing problems quickly. I’m generally attracted to emergent, rather than top-down, organization, and I think order often arises best through iteration and feedback.

    Like @PhilTurmel, I’m a solo software developer. My own niche is machine control and embedded systems, mostly in factory automation. There’s no practical DevOps approach to what I do: that is, it’s hard to do frequent software releases into a distant customer’s industrial equipment, given the nature of embedded controllers, network security issues in clients’ establishments, and the lack of on-site technical expertise. On the other hand, on those occasions when I do get to do more conventional development, I try to embrace more of the fluidity of agile by avoiding overly complicated and rigid initial specs, focusing on rapid incremental delivery, and encouraging feedback. I think it works well, and it’s certainly more fun.

    Great post. Thanks!

    • #7
  8. Bartholomew Xerxes Ogilvie, Jr. Coolidge
    Bartholomew Xerxes Ogilvie, Jr.
    @BartholomewXerxesOgilvieJr

    During the last decade and a half I have worked on multiple projects that called themselves Agile. I have found that Agile can work well, but only when a team adopts it seriously. Most of the so-called Agile projects I’ve been on have adopted certain aspects of Agile without really committing to it. Having a thrice-weekly “scrum” that lasts over an hour isn’t agile. That’s just an old-fashioned status meeting, and by having it more often you’re just wasting even more of your people’s time.

    The main problem I’ve seen with Agile is that it is often used as an excuse to not design anything. But Agile doesn’t mean “make it up as you go along.” I mainly work on customer-facing documentation, and it’s hard to write docs when you have no spec and no clear explanation of what will be shipped.

    One of things I really like about Agile, though, is that it tends to keep plans closer to reality. When you’re working on a “waterfall” project with a long development cycle, it’s easy to end up with a release plan that is impossible to achieve. Everybody ends up working overtime, and eventually the release gets delayed. With Agile, especially in a continuous-delivery world, you do whatever you can fit into a particular iteration; if you can’t finish it in this iteration, you break it into smaller pieces and move some of the pieces later. That can be abused as well, of course, but I think it does keep everybody a bit more honest about what’s possible.

    • #8
  9. Arahant Member
    Arahant
    @Arahant

    My Mentor likes to say, “There are some businesses where you can go from concept to product in a day. Florists and candy makers are among them. Someone comes up with chocolate-dipped potato chips. You get down to the end of the bag and realize you have a lot of broken and unsuitable pieces. What do you do? Come up with a new product. Chocolate bars with potato chip pieces in them. It’s fast adaptation. If they don’t sell, you find a new thing to do with them. Caramel apples rolled in potato chips pieces instead of nuts? We can try that. From concept to shelves in less than a day.”


    This conversation is an entry in our Group Writing Series under September’s theme of Order. We still have a dozen days open. If you would like to share something about order or disorder, emergent or divergent, come sign up. I saw someone say that Ricochet was now all focused on one single subject, but it isn’t true, and Group Writing is one of the things that brings more interesting topics for us to share. Our sign-up sheet is waiting, and you know you have it in you.

    • #9
  10. Judge Mental Member
    Judge Mental
    @JudgeMental

    Arahant (View Comment):

    My Mentor likes to say, “There are some businesses where you can go from concept to product in a day. Florists and candy makers are among them. Someone comes up with chocolate-dipped potato chips. You get down to the end of the bag and realize you have a lot of broken and unsuitable pieces. What do you do? Come up with a new product. Chocolate bars with potato chip pieces in them. It’s fast adaptation. If they don’t sell, you find a new thing to do with them. Caramel apples rolled in potato chips pieces instead of nuts? We can try that. From concept to shelves in less than a day.”

    My strategy was to get something in front of the users as quickly as possible, so they can start using it to achieve some of the goals.  From that point, my approach was, “what can I do today, what can I do this week, what can I do this month?”.

    From a contracting standpoint, this is also nice because the development is never really done.  Even after you’ve achieved all of the original goals, they’ll have thought of new things.  And given that most environments now seem to be constantly changing, your software must continuously adapt to the new environment.

    • #10
  11. Arahant Member
    Arahant
    @Arahant

    Bartholomew Xerxes Ogilvie, Jr. (View Comment):
    Most of the so-called Agile projects I’ve been on have adopted certain aspects of Agile without really committing to it.

    This is true of every new method-of-the-week that comes along. Many projects that were being called Business Process Re-Engineering were nothing like it. If you’re just laying people off, that isn’t BPR.

    • #11
  12. Clavius Thatcher
    Clavius
    @Clavius

    Bartholomew Xerxes Ogilvie, Jr. (View Comment):

    During the last decade and a half I have worked on multiple projects that called themselves Agile. I have found that Agile can work well, but only when a team adopts it seriously. Most of the so-called Agile projects I’ve been on have adopted certain aspects of Agile without really committing to it. Having a thrice-weekly “scrum” that lasts over an hour isn’t agile. That’s just an old-fashioned status meeting, and by having it more often you’re just wasting even more of your people’s time.

    The main problem I’ve seen with Agile is that it is often used as an excuse to not design anything. But Agile doesn’t mean “make it up as you go along.” I mainly work on customer-facing documentation, and it’s hard to write docs when you have no spec and no clear explanation of what will be shipped.

    One of things I really like about Agile, though, is that it tends to keep plans closer to reality. When you’re working on a “waterfall” project with a long development cycle, it’s easy to end up with a release plan that is impossible to achieve. Everybody ends up working overtime, and eventually the release gets delayed. With Agile, especially in a continuous-delivery world, you do whatever you can fit into a particular iteration; if you can’t finish it in this iteration, you break it into smaller pieces and move some of the pieces later. That can be abused as well, of course, but I think it does keep everybody a bit more honest about what’s possible.

    You are correct that Agile is often used as an excuse not to plan or design.  That tendency is a permanent fixture in system development.  With each new technology, be it relational databases, client server, whatever, many people take it as an excuse to throw out the care that is required to build a quality application that can be maintained.

    You are also on point with the tendency to be “Agile in name only.”  That is a huge risk as people resist change and so just change the names of what they do instead of changing what they do.  We had a consultant recently tell us about a project they joined where their daily stand-up lasted eight hours.  It was just a long group working session.

    Putting code into production is the best way to keep people honest and plans closer to reality.  You are spot on.

    • #12
  13. Danny Alexander Member
    Danny Alexander
    @DannyAlexander

    Here in Japan, it has been weird being involved in pilot Agile efforts a couple years back, then being away from them for a time, and now wanting to be back involved in them again.

    (I consult in enterprise process improvement [both “upstream” from software projects, as well as at the interface between org dev and project implementation], along with software project management, and requirements/backlog elaboration and management.)

    There are increasing numbers of Japanese who do indeed “get it,” and more importantly have a constructive idea of how to make “it” work in decidedly Japanese enterprise contexts.  This is a fortunate thing.

    The unfortunate thing is that the IT professional services category called “SI” or System Integrator is profoundly dug in as a difficult-to-circumvent “partner” in developing and operating enterprise software systems here, and the “SIer” business model (and the legal framework for contracts) is at base inimical to a healthy, fast-moving, and intelligently risk-conscious approach towards advancing Agile.

    I’d like to think that SAFe (Scaled Agile Framework, in its current v4.5 form) could help dislodge the SIers and transform the relationship dynamic between enterprises and their IT professional services vendors, but the SIers here are “going to the mattresses” against such attempts — while simultaneously, of course, portraying themselves in the PR arena as embracing Agile.

    In any case, I would heartily recommend Mark Schwartz’s books, in particular his most recent one “A Seat at the Table,” as a way of re-setting executive-level thinking about the why’s and wherefore’s of Agile as it relates not only to IT managerial leadership but indeed in conjunction with corporate/enterprise leadership and business strategy future directions.

    • #13
  14. MeanDurphy Member
    MeanDurphy
    @DeanMurphy

    In our move toward Agile, I find that the most resistant to it are the people who were formerly identified as “business analysts” and now are trying to be “Product Owners.”   The actual production owners are being kept at arms length.  The “PO’s” in put team are still trying to steer certain tasks toward certain people, to the point where they won’t put anything in the “ready to work” lane until they know who is ready to pick it up.

    Otherwise, I think it’s working well in our shop.  I used to be pigeon-holed into one system, now I get to work in different areas.

    • #14
  15. Danny Alexander Member
    Danny Alexander
    @DannyAlexander

    #14 MeanDurphy

    Hugely valuable comment re the PO’s reluctance to OK dev work until assured of who’s assigned to the work.  (Depressing, but valuable.)

    Weak executive sponsorship?  Weak ScrumMasters?

    The observation about BA’s being in limbo and attempting to re-cast themselves as PO’s is something I’ve seen; personally, I don’t consider it to be imprudent or heretical to experiment with such role shifts, but the risk as I see it is business-side PO’s lazily delegating everything out to “deputized” BA’s acting as their representatives to the dev teams.  That simply replicates the pre-Agile paradigm, and allows PO’s to evade accountability into the bargain.

    • #15
  16. Arahant Member
    Arahant
    @Arahant

    MeanDurphy (View Comment):
    the people who were formerly identified as “business analysts”

    • #16
  17. Clavius Thatcher
    Clavius
    @Clavius

    Danny Alexander (View Comment):

    Here in Japan, it has been weird being involved in pilot Agile efforts a couple years back, then being away from them for a time, and now wanting to be back involved in them again.

    (I consult in enterprise process improvement [both “upstream” from software projects, as well as at the interface between org dev and project implementation], along with software project management, and requirements/backlog elaboration and management.)

    There are increasing numbers of Japanese who do indeed “get it,” and more importantly have a constructive idea of how to make “it” work in decidedly Japanese enterprise contexts. This is a fortunate thing.

    The unfortunate thing is that the IT professional services category called “SI” or System Integrator is profoundly dug in as a difficult-to-circumvent “partner” in developing and operating enterprise software systems here, and the “SIer” business model (and the legal framework for contracts) is at base inimical to a healthy, fast-moving, and intelligently risk-conscious approach towards advancing Agile.

    I’d like to think that SAFe (Scaled Agile Framework, in its current v4.5 form) could help dislodge the SIers and transform the relationship dynamic between enterprises and their IT professional services vendors, but the SIers here are “going to the mattresses” against such attempts — while simultaneously, of course, portraying themselves in the PR arena as embracing Agile.

    In any case, I would heartily recommend Mark Schwartz’s books, in particular his most recent one “A Seat at the Table,” as a way of re-setting executive-level thinking about the why’s and wherefore’s of Agile as it relates not only to IT managerial leadership but indeed in conjunction with corporate/enterprise leadership and business strategy future directions.

    Mark Schwartz’s books are great!

    It is ironic that Japanese SI companies struggle with Agile since so many of the principles of Agile arose from The Toyota Way.

    • #17
  18. Clavius Thatcher
    Clavius
    @Clavius

    MeanDurphy (View Comment):

    In our move toward Agile, I find that the most resistant to it are the people who were formerly identified as “business analysts” and now are trying to be “Product Owners.” The actual production owners are being kept at arms length. The “PO’s” in put team are still trying to steer certain tasks toward certain people, to the point where they won’t put anything in the “ready to work” lane until they know who is ready to pick it up.

    Otherwise, I think it’s working well in our shop. I used to be pigeon-holed into one system, now I get to work in different areas.

    That is a hard transition.  Better to make the BAs team members who do backlog refinement and testing and maybe even learn some coding. 

    And cross-functionality is great.

    • #18
  19. Clavius Thatcher
    Clavius
    @Clavius

    Danny Alexander (View Comment):

    #14 MeanDurphy

    Hugely valuable comment re the PO’s reluctance to OK dev work until assured of who’s assigned to the work. (Depressing, but valuable.)

    Weak executive sponsorship? Weak ScrumMasters?

    The observation about BA’s being in limbo and attempting to re-cast themselves as PO’s is something I’ve seen; personally, I don’t consider it to be imprudent or heretical to experiment with such role shifts, but the risk as I see it is business-side PO’s lazily delegating everything out to “deputized” BA’s acting as their representatives to the dev teams. That simply replicates the pre-Agile paradigm, and allows PO’s to evade accountability into the bargain.

    Exactly.

    • #19
  20. Arahant Member
    Arahant
    @Arahant

    Clavius (View Comment):

    That is a hard transition. Better to make the BAs team members who do backlog refinement and testing and maybe even learn some coding. 

    And cross-functionality is great.

    A good BA should have started as a coder.

    • #20
  21. Clavius Thatcher
    Clavius
    @Clavius

    Arahant (View Comment):

    Clavius (View Comment):

    That is a hard transition. Better to make the BAs team members who do backlog refinement and testing and maybe even learn some coding.

    And cross-functionality is great.

    A good BA should have started as a coder.

    I can’t argue with that.

    • #21
  22. Judge Mental Member
    Judge Mental
    @JudgeMental

    Clavius (View Comment):

    Arahant (View Comment):

    Clavius (View Comment):

    That is a hard transition. Better to make the BAs team members who do backlog refinement and testing and maybe even learn some coding.

    And cross-functionality is great.

    A good BA should have started as a coder.

    I can’t argue with that.

    I can.  Not talking about Agile, but in general.  The best BAs I’ve seen are attractive young women.  Not super-hot, but attractive.  Because their job is to get other people to describe their jobs in detail.  Women prefer to deal with women, as long as they aren’t too pretty.  And men enjoy being the center of an attractive young woman’s attention.

    • #22
  23. Arahant Member
    Arahant
    @Arahant

    Judge Mental (View Comment):
    The best BAs I’ve seen are attractive young women. Not super-hot, but attractive. Because their job is to get other people to describe their jobs in detail. Women prefer to deal with women, as long as they aren’t too pretty. And men enjoy being the center of an attractive young woman’s attention.

    That does not mean they can’t have a base of coding experience.

    • #23
  24. Judge Mental Member
    Judge Mental
    @JudgeMental

    Arahant (View Comment):

    Judge Mental (View Comment):
    The best BAs I’ve seen are attractive young women. Not super-hot, but attractive. Because their job is to get other people to describe their jobs in detail. Women prefer to deal with women, as long as they aren’t too pretty. And men enjoy being the center of an attractive young woman’s attention.

    That does not mean they can’t have a base of coding experience.

    Didn’t say they can’t, just that it’s not necessary.  Out of the group of four that I have in mind, one of them had taken some classes in college.

    • #24
  25. Miffed White Male Member
    Miffed White Male
    @MiffedWhiteMale

    Agile – Back in the ’80s we called it “prototyping”.

    Of course, in the 1970s cloud computing was called “timesharing”.

    Everything that’s old is new again.

     

    • #25
  26. Miffed White Male Member
    Miffed White Male
    @MiffedWhiteMale

    Generalized Management Handbook:

    1:  Centralize that which is decentralized.  Decentralize that which is Centralized.

    2:  Wait 5-10 years, then repeat #1

    • #26
  27. Clavius Thatcher
    Clavius
    @Clavius

    Miffed White Male (View Comment):

    Generalized Management Handbook:

    1: Centralize that which is decentralized. Decentralize that which is Centralized.

    2: Wait 5-10 years, then repeat #1

    Ha, so true.

    • #27
  28. Eb Snider Member
    Eb Snider
    @EbSnider

    I very much like this post and I think you described the basic concept clearly. I also identify with the topic having worked in two giant international companies. I’m not IT though. I worked in industrial and energy operations and in quest-technical roles that used software and had to deal with bungling by management and the sometimes erratic nature of the clients.  I have come to believe that a flatter management structure is frequently much better than a large pyramid of top down orders approach. Only doing what one is told, and the view of individuals having their own ideas as a hazard. 

    Most managers I’ve seen were mediocre to bad and were frequently clueless on how to add value, so superfluous additional paperwork, procedures, and emails are generated. Calling a meeting or putting out the latest fad thing that will wash out in 6 months is considered an accomplishment. Basically people in an organization structure trying to look like they’re doing something to keep a position or ladder climb. Perhaps there’s a name for this condition. And frequently those other managers that were good or still in the energetic phase of life close to operations didn’t have the authority or means to make required adjustments. And addressing problems frankly and directly could cause problems for those reform minded managers because it might be taken as an indictment on those above and thus damage career advancement through the ranks. I notice that incentives can be a big issue. Things are not always so straight forward and tying to do a good job and helping your company provide a quality service. Middle managers sometimes don’t have the same goals of implementing policies (especially when they are difficult to comply with) from above nor do they necessarily have the incentive to help the workers under their direction. This is a peculiar bureaucratic issue. 

    I prefer a system when involved members can more readily address issues that are identified – instead of being passive workers waiting to be directed. Having targeted control and authority to correct issues that you and a team deal with on a regular basis rather than waiting for some removed person to take action on something he doesn’t have specific knowledge of or might not even care about. “Hey, that’s not my problem!” It doesn’t mean that a team will always provide the best solution, but it does mean more issues can have solutions not only proposed but worked on. One aspect of real operations in companies perhaps under identified is that time, effort, and resources can get wasted simply because of additional work created by inefficiencies within a system of an organization. 

    • #28
  29. Clavius Thatcher
    Clavius
    @Clavius

    Eb Snider (View Comment):

    I very much like this post and I think you described the basic concept clearly. I also identify with the topic having worked in two giant international companies. I’m not IT though. I worked in industrial and energy operations and in quest-technical roles that used software and had to deal with bungling by management and the sometimes erratic nature of the clients. I have come to believe that a flatter management structure is frequently much better than a large pyramid of top down orders approach. Only doing what one is told, and the view of individuals having their own ideas as a hazard.

    Most managers I’ve seen were mediocre to bad and were frequently clueless on how to add value, so superfluous additional paperwork, procedures, and emails are generated. Calling a meeting or putting out the latest fad thing that will wash out in 6 months is considered an accomplishment. Basically people in an organization structure trying to look like they’re doing something to keep a position or ladder climb. Perhaps there’s a name for this condition. And frequently those other managers that were good or still in the energetic phase of life close to operations didn’t have the authority or means to make required adjustments. And addressing problems frankly and directly could cause problems for those reform minded managers because it might be taken as an indictment on those above and thus damage career advancement through the ranks. I notice that incentives can be a big issue. Things are not always so straight forward and tying to do a good job and helping your company provide a quality service. Middle managers sometimes don’t have the same goals of implementing policies (especially when they are difficult to comply with) from above nor do they necessarily have the incentive to help the workers under their direction. This is a peculiar bureaucratic issue.

    I prefer a system when involved members can more readily address issues that are identified – instead of being passive workers waiting to be directed. Having targeted control and authority to correct issues that you and a team deal with on a regular basis rather than waiting for some removed person to take action on something he doesn’t have specific knowledge of or might not even care about. “Hey, that’s not my problem!” It doesn’t mean that a team will always provide the best solution, but it does mean more issues can have solutions not only proposed but worked on. One aspect of real operations in companies perhaps under identified is that time, effort, and resources can get wasted simply because of additional work created by inefficiencies within a system of an organization.

    Yes, Theory Y produces better results in almost all situations.  Certainly not limited to IT.  Thank you for your thoughts.

    • #29
  30. MeanDurphy Member
    MeanDurphy
    @DeanMurphy

    One of our PO’s has limited coding experience, one actually came from the “ops” (company ops not computer ops) section, the other 3 are variously experienced with Project Management.  Our Scrum Master has her work cut out for her, especially with the most senior of the former PM’s.  The OPM wants to run everything and has strong opinions on who should be trusted to do what.

    mostly they collect requirements, determine priority, and act as liaison to the business.

    The ops person isn’t as involved as I would prefer.

    Kanban team:

    1 Scrum Master

    5 PO’s

    5 devs (me included)

    2 QA/Testers

    2 week target for story completion (abt 45% on target)

    Supposed to be 1 story per dev, but I’ve had up to 3 (average 1.5 so far)

    • #30
Become a member to join the conversation. Or sign in if you're already a member.