Another IT thread- stress level

[GwinnettNole]

I've notice a trend at the company I worked for and the one I transferred to (all under the same umbrella) that with the agile methodology things are much faster passed which includes more workable parts/pieces being delivered--- which is good.... but it has also required more hours from staff and the stress level is higher as well.

Is this a company specific thing or is this across the industry?

Agile, by design is supposed to deliver things more quickly-- but I've noticed with two weeks sprints it gives very little time for error/ rework/ and testing. In the old waterfall world a "workable product" was not required every two weeks-- rather a big bang every few months or so. No one gave a flip about tech designs, or test cases so the move to agile has elimated a lot of that. But has been replaced by the more stress driven "workable product".

Don't get me wrong-- I really like agile and have become a CSM. I like less documentation and less BS work. But the offset has been more pressure, stress and hours (from DEV and QA). Is this just unique to the company I'm at?

 

[fsunole025]

What you are experiencing is not unique to your company. I have been an Agile Coach and Trainer since 2011 and there are a lot of misconceptions throughout the IT industry regarding Agile/Scrum frameworks. Please do not interpret that statement as "you don't know what you're talking about". The only context I have is what you have posted here today and in the past. So, I am in no position to judge you or your organization's Agile implementation. It would be extremely foolish of me to do so.

Delivery teams work in sprints but Agile is not about being fast. It is being able to make adjustments to deliver value to our customers without resistance or waste. Organizations need to think of Agile as being flexible at a sustainable pace giving our customers (Product Owner as proxy) an opportunity to reconcile their ideas or "asks" with reality (demo working software). Most customers do not really know what they want until they see something. The IKIWISI principle (I'll Know It When I See It) applies at all times.

What typically is company specific is leadership's understanding of Agile principles and practices. At this point in my coaching career, I mostly engage as a program and portfolio coach with large enterprises applying Agile at scale (SAFe) principles. Just as with Lean manufacturing or product development flow, the foundation of Agile/SAFe success is Lean leadership. Do the leaders in your organization know more about Lean concepts than the Scrum teams? They should.

Most often, teams are stressed because of pressures imposed on them by leadership that is not based on Lean thinking. This leads to an unsustainable pace resulting in burnout, defects, rework etc. If the team you referred to in your original post has very little time for rework I would focus on two areas of improvement: 1) root cause analysis on why they have so much rework and 2) why are they overcommitting during Sprint Planning?

Additionally, most enterprises adopting Agile principles and practices put most of their focus on the "process" but do not evolve their technical best practices. Have your teams adopted continuous integration (CI), Test Driven Development (TDD), Behavior Driven Development (BDD), etc. best practices? They might benefit from some technical coaching. Additionally, are they taking items from their retrospectives and creating backlog items to improve how they deliver?

My recommendation would be to contact someone and have an Agile assessment completed on your organization, not just the teams. Even if you don't intend on having coaches come in and help accelerate improvements throughout the organization, an assessment can help leaders and the teams understand where to focus their attention for continuous improvement.

 

[YogiNole]

What @fsunole025 said, Agile does not simply mean IT or software, the entire org needs to be that way. One of the great perks of doing a startup is you can structure your company top-down to be Agile.

 

[fsunole025]

Yogi, are you part of a startup that uses Lean/Agile concepts? I'm always looking for new ideas to apply startup concepts at large enterprises. Startups are the best innovators because they have little to no constraints other than cash flow.

 

[YogiNole]

Yogi, are you part of a startup that uses Lean/Agile concepts? I'm always looking for new ideas to apply startup concepts at large enterprises. Startups are the best innovators because they have little to no constraints other than cash flow.

We use lean methodology company-wide to iterate and build. Software development uses Agile methodology and templates but any serious practitioner would laugh at us. That is the point though, we make do with our limited resources and keep building cutting edge tech

 

[fsunole025]

@YogiNole Let me know if you ever want to connect. I have some volunteer hours that I need to use for some of my certs. They would likely need to be virtual but I would love to learn more about what your shop is doing.

 

[MuchasVeces]

I've only done Scrum from the dev side. In my experience, it's less stressful than the other ad hoc systems under which I've worked.

 

[funksouljon]

But the offset has been more pressure, stress and hours (from DEV and QA). Is this just unique to the company I'm at?

Short answer from a Agile Shop in a waterfall organization is "No, not unique at all". But I have been in agile shops where the stress is much lower. I'd also say, I see a lot of push back or incomplete releases due to the PO expectation of "We thought you would just know/do that! It should be implied with the stories you wrote and delivered, therefore we will create a defect." <facepalm>

We run a good sized SAFE program in a top 5 health care organization. In addition to some of the general stress that come with agile development, is we are agile in a waterfall organization. Our leadership are all waterfall PMs that have been hired since they are "managers". It's all the same isn't it?

fsunole25 - Do the leaders in your organization know more about Lean concepts than the Scrum teams? They should. This made me laugh, not cause I disagree with you, but how bad we are in this arena.

 

[fsunole025]

fsunole25 - Do the leaders in your organization know more about Lean concepts than the Scrum teams? They should. This made me laugh, not cause I disagree with you, but how bad we are in this arena.

@funksouljon - We've adopted the approach that we will not engage in a SAFe transformation unless the leaders that can directly influence change attend a Leading SAFe course. I just launched an ART at a financial enterprise that has 20 teams (~200 people) and it is already more successful in the first PI than several much smaller ARTs that we launched at a logistics enterprise. The difference? Leadership. We have plans to launch several more ARTs within the same organization.

 

[GwinnettNole]

What you are experiencing is not unique to your company. I have been an Agile Coach and Trainer since 2011 and there are a lot of misconceptions throughout the IT industry regarding Agile/Scrum frameworks. Please do not interpret that statement as "you don't know what you're talking about". The only context I have is what you have posted here today and in the past. So, I am in no position to judge you or your organization's Agile implementation. It would be extremely foolish of me to do so.

Delivery teams work in sprints but Agile is not about being fast. It is being able to make adjustments to deliver value to our customers without resistance or waste. Organizations need to think of Agile as being flexible at a sustainable pace giving our customers (Product Owner as proxy) an opportunity to reconcile their ideas or "asks" with reality (demo working software). Most customers do not really know what they want until they see something. The IKIWISI principle (I'll Know It When I See It) applies at all times.

What typically is company specific is leadership's understanding of Agile principles and practices. At this point in my coaching career, I mostly engage as a program and portfolio coach with large enterprises applying Agile at scale (SAFe) principles. Just as with Lean manufacturing or product development flow, the foundation of Agile/SAFe success is Lean leadership. Do the leaders in your organization know more about Lean concepts than the Scrum teams? They should.

Most often, teams are stressed because of pressures imposed on them by leadership that is not based on Lean thinking. This leads to an unsustainable pace resulting in burnout, defects, rework etc. If the team you referred to in your original post has very little time for rework I would focus on two areas of improvement: 1) root cause analysis on why they have so much rework and 2) why are they overcommitting during Sprint Planning?

Additionally, most enterprises adopting Agile principles and practices put most of their focus on the "process" but do not evolve their technical best practices. Have your teams adopted continuous integration (CI), Test Driven Development (TDD), Behavior Driven Development (BDD), etc. best practices? They might benefit from some technical coaching. Additionally, are they taking items from their retrospectives and creating backlog items to improve how they deliver?

My recommendation would be to contact someone and have an Agile assessment completed on your organization, not just the teams. Even if you don't intend on having coaches come in and help accelerate improvements throughout the organization, an assessment can help leaders and the teams understand where to focus their attention for continuous improvement.

Thanks this is good info.

I also laugh at the thought of the entire organization being agile-- at least at my prior work location. The current one is smaller and there is this mindset. I think the team is overcommitting each sprint... we have developers that are way too aggressive and it ends up shooting ourselves in the foot.

 

[YogiNole]

Thanks this is good info.

I also laugh at the thought of the entire organization being agile-- at least at my prior work location. The current one is smaller and there is this mindset. I think the team is overcommitting each sprint... we have developers that are way too aggressive and it ends up shooting ourselves in the foot.

The thing with overcommiting is, if you go back and do sprint reviews and figure out team velocity, burn rate and other metrics you can clearly prove that your team is overcommiting or under estimating

 

[YogiNole]

@YogiNole Let me know if you ever want to connect. I have some volunteer hours that I need to use for some of my certs. They would likely need to be virtual but I would love to learn more about what your shop is doing.

I sent you my email address in a message on here. Not sure how that work on your end.