Software - Moving from Waterfall to Agile

[HookEm 2467]

I'm a Technology Director at an Austin division of a fortune-500 company making industrial software / hardware products.  We are finally making the jump from Waterfall-ish 2-3 year release cycles to Agile (SAFe).  We have had a variety of consultants helping us plan to make the jump, but we are really just getting started.

I'm looking for advice from folks who have actually gone through this.  We will have ~300 software developers + testers worldwide working on a main system and a number of smaller software products.  Some are certified by various bodies.  Some have hardware components.

So please post tips here.  Would love your thoughts regardless of whether you were an engineer in the trenches or an executive leading the whole thing.

Also PM me if you are open to a longer off-line conversation.  Thanks!

[Doc Holliday 199]

Stay in your lane and allow the freedom for your developers, scrum masters, etc. to do their thing.  Executives should NOT get involved in the weeds of the product development lifecycle.   They need to trust the product owner and team members.  Communication is extremely important during this transition. 

As a leader, focus on your priorities within the methodology and stick to them.   Don't go bouncing around trying to change the world, yet.  Become successful with your sprints and tracking your burn downs. Then transition into additional nuances of what agile means.  

My advice is to focus on release management and the subsequent process flow.  Once your team(s) are in a good groove, you should be releasing updates as often as every week to maybe once every 4 weeks. 

Test, test, test and test again. 

Back-log grooming and understanding what is most impactful to your business (revenue stream, customer base, customer base opinions, etc.) is also vitally important.  Don't over promise anything, yet. 

Invest in post-it notes.

 

[Celery Man 20962]

Subscribed

[Celery Man 20962]

I started a related topic on the old board (regarding being a "product owner" for an agile software development team) and there was a little bit of good discussion.  I'm still finding my way a bit - new to managing a cross functional agile team in a devops fashion.  We have a mature product that we're trying to ultimately move towards all of the continuous integration/continuous development stuff, reduce the cost of maintenance and delivery, but also getting bogged down in that same stuff.  I don't think I can give you any tips of success yet, but I've found pluralsight to be a pretty good resource for good video classes on whatever relevant subjects, and I like to peruse youtube for relevant talks/videos, to at least get as much osmosis of good ideas going as I can

 

[Doc Holliday 199]

I did all of my Agile training with Angela Bruckman.  She has some good books, insights, and knows her stuff.  If you need training, I highly recommend her.

[Judge Roybeanbag 11819]

On 4/27/2018 at 3:39 PM, Doc Holliday said:

Stay in your lane and allow the freedom for your developers, scrum masters, etc. to do their thing.  Executives should NOT get involved in the weeds of the product development lifecycle.   They need to trust the product owner and team members.  Communication is extremely important during this transition. 

As a leader, focus on your priorities within the methodology and stick to them.   Don't go bouncing around trying to change the world, yet.  Become successful with your sprints and tracking your burn downs. Then transition into additional nuances of what agile means.  

My advice is to focus on release management and the subsequent process flow.  Once your team(s) are in a good groove, you should be releasing updates as often as every week to maybe once every 4 weeks. 

Test, test, test and test again. 

Back-log grooming and understanding what is most impactful to your business (revenue stream, customer base, customer base opinions, etc.) is also vitally important.  Don't over promise anything, yet. 

Invest in post-it notes.

 

I’ll add don’t get so caught up in the process that you lose sight of the customer. 

[Judge Roybeanbag 11819]

2 hours ago, Doc Holliday said:

I did all of my Agile training with Angela Bruckman.  She has some good books, insights, and knows her stuff.  If you need training, I highly recommend her.

What tools do you use to manage sprints?  We use this antiquated thing called Version one.  

Edited April 30, 2018 by Judge Roybeanbag

[SmokeyTheBear 5562]

We use JIRA and it works well for Agile. We are just now moving our teams from Waterfall to Agile and it is fairly simple if you take whatever has already been said above into account. Run it for a few months then have retrospectives to see what the team thinks works/doesn't and make small adaptations to the methodology. 

[Judge Roybeanbag 11819]

20 minutes ago, SmokeyTheBear said:

We use JIRA and it works well for Agile. We are just now moving our teams from Waterfall to Agile and it is fairly simple if you take whatever has already been said above into account. Run it for a few months then have retrospectives to see what the team thinks works/doesn't and make small adaptations to the methodology. 

Godzilla.  

[BillyBadAss 189]

I prefer a Kanban or Scumban model to Scrum. Running fixed-length sprints  to me is arbitrary and wasteful and rarely in my experience works. 

Some reasons I don't like sprints:

What if I'm coming up to the end of the sprint and running behind? Do I cut some corners to get it complete? Do I have the work cross over into the next sprint( now have to document a bunch of extra stuff).

What if I finish my tasks earlier than expected in the Sprint. Do I take it easy for a day or two waiting for the Sprint to end? 

What if you have dedicated testing teams waiting on development to finish something? Are they waiting around til the end of the sprint for something to do? Or are their sprints staggered? That requires extra planning. 

What if you don't foresee something, or something new comes up that is critical? It interrupts your sprint, or it waits. 

With Kanban, you simply maintain a list of things to do, prioritize them, and as team members finish a task, they can take the next task off the top of the board and start working on it. The to-do list can be constantly updated and modified. Much more flexible, IMO. If something critical comes up, you can start work on it right away. If you forget something, you can add it in right away. If you have a dev-test pipeline, tasks can move from team to team whenever they are ready to move. If a task is easier than expected, great. Take up the next task when you complete it. If a task is harder, no problem - work on it until it is complete. 

 

[Bigpoppapump 531]

1 hour ago, BillyBadAss said:

I prefer a Kanban or Scumban model to Scrum. Running fixed-length sprints  to me is arbitrary and wasteful and rarely in my experience works. 

Some reasons I don't like sprints:

What if I'm coming up to the end of the sprint and running behind? Do I cut some corners to get it complete? Do I have the work cross over into the next sprint( now have to document a bunch of extra stuff).

What if I finish my tasks earlier than expected in the Sprint. Do I take it easy for a day or two waiting for the Sprint to end? 

What if you have dedicated testing teams waiting on development to finish something? Are they waiting around til the end of the sprint for something to do? Or are their sprints staggered? That requires extra planning. 

What if you don't foresee something, or something new comes up that is critical? It interrupts your sprint, or it waits. 

With Kanban, you simply maintain a list of things to do, prioritize them, and as team members finish a task, they can take the next task off the top of the board and start working on it. The to-do list can be constantly updated and modified. Much more flexible, IMO. If something critical comes up, you can start work on it right away. If you forget something, you can add it in right away. If you have a dev-test pipeline, tasks can move from team to team whenever they are ready to move. If a task is easier than expected, great. Take up the next task when you complete it. If a task is harder, no problem - work on it until it is complete. 

 

I agree. The nature of my team means various sizes of projects with very tough scoping efforts some times.  And I've noticed all the other teams that are scrum have very bored developers.

[SmokeyTheBear 5562]

1 hour ago, BillyBadAss said:

I prefer a Kanban or Scumban model to Scrum. Running fixed-length sprints  to me is arbitrary and wasteful and rarely in my experience works. 

Some reasons I don't like sprints:

What if I'm coming up to the end of the sprint and running behind? Do I cut some corners to get it complete? Do I have the work cross over into the next sprint( now have to document a bunch of extra stuff).

What if I finish my tasks earlier than expected in the Sprint. Do I take it easy for a day or two waiting for the Sprint to end? 

What if you have dedicated testing teams waiting on development to finish something? Are they waiting around til the end of the sprint for something to do? Or are their sprints staggered? That requires extra planning. 

What if you don't foresee something, or something new comes up that is critical? It interrupts your sprint, or it waits. 

With Kanban, you simply maintain a list of things to do, prioritize them, and as team members finish a task, they can take the next task off the top of the board and start working on it. The to-do list can be constantly updated and modified. Much more flexible, IMO. If something critical comes up, you can start work on it right away. If you forget something, you can add it in right away. If you have a dev-test pipeline, tasks can move from team to team whenever they are ready to move. If a task is easier than expected, great. Take up the next task when you complete it. If a task is harder, no problem - work on it until it is complete. 

 

Really depends on the organization. We use Agile in a common goods service type environment so our focus is on maintenance and feature enhancements. We have fixed released dates so a steady sprint schedule works well. And as long as you have a few items in your backlog, there should always be something for someone to do. Of course the general framework can be adapted to fit each organizations mode. I actually installed something of an Agile method to our operations team which has worked out well. 

[Horn of Gabriel 1614]

Agile helps you run faster/more efficiently.  Just don't forget to run in the right direction.  The former is the job of the Agile team, the latter (should be) the job of product management.

Don't make your product managers into product owners just because they both have "product" in the title.  Different roles, with different foci.

[BillyBadAss 189]

I'm definitely all for Agile methodologies. But there are several Agile development methods. Agile Scrum is one that is widely used , of which I am not a fan. 

Some good info here, including the 12 principles of agile development. 

https://en.wikipedia.org/wiki/Agile_software_development

Quote

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

Quote

Agile software development principles

The Manifesto for Agile Software Development is based on twelve principles:

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

 

Edited May 1, 2018 by BillyBadAss

[thunderlounge 7844]

 

[HookEm 2467]

Thanks for all the replies.

How are you guys scaling agile for those in larger organizations? We are considering using SAFe as our model. Anybody using it?

[Celery Man 20962]

Not sure about SAFe (I need to learn about what that is), and not on the scale that you're talking about, but we at one point had our software group organized into "squads" appropriately sized as scrum teams (I think ~8 people).  We had a technical program manager coordinating with product to assign features and work with the scrum masters for each squad on scheduling work for sprints.

[0xdeadbeef 1651]

On 4/30/2018 at 2:18 PM, BillyBadAss said:

...

Some reasons I don't like sprints:

What if I'm coming up to the end of the sprint and running behind? Do I cut some corners to get it complete? Do I have the work cross over into the next sprint( now have to document a bunch of extra stuff).

 ...

A number of years ago I did some work with a large company that had switched a year earlier over to an Agile/Scrum model for software development.     They had been doing Sprints almost non-stop for almost 9 months and their software development team was just completely burnt out.   Perhaps some of the fault was the folks they had running things, and perhaps it was their emphasis on not missing a sprint deadline,  but whatever the reason, the stress and anxiety of a deadline every two weeks killed their development team.  It was a terrible environment to work in and they were paying the price with high developer turnover and apathy.

As an outsider looking at them  it was clear they had a self-inflicted problem caused by their process, but their management, in the thick of it, couldn't see it.

 

 

[Celery Man 20962]

I feel like I should preface every post with a disclaimer that I'm a newb in this role (product owner) and am figuring it out.

I was running an ops group doing kanban, and am now managing/"product owning" a cross functional product team that does a mix of development and ops.  On the scrum conversation, I do find that it's difficult to make sure that development stories are getting the time/love they need with ops/delivery stuff always trying to jump to the top of the board.  There are a lot of ways to combat this probably, but we're trying to do a loose scrum/kanban mix - planning features in a scrum fashion with two week sprints, but not such that it is 100% capacity for the developers.  But enough that we're definitely aiming for getting a specified set of stories completed in the two week sprint.  I don't think we've quite hit the right mix yet, but we're improving.

We did try doing planning poker while planning this time around, and that was really useful to me (not being a software dev, it's not always totally obvious to me the amount of work that's going to go into completing a story) and a not horrible way to get the whole team involved in talking about what we're going to do.

[thunderlounge 7844]

We switched a few years ago from quarterly sprints to deploying whatever is ready every week. Much prefer the second option, as you’re not stuck with things that took two weeks to do being delayed into production for 10 weeks. 

Bug fixes were always asap, but it seems to flow better this way. Whichever approach is better depends on the app, environment, and clients. 

[Celery Man 20962]

We do big releases in a quarterly basis and I hate it. It’s a total pain in the ass, but our release/deploy process is... a million times better than it was a year ago but still breaks more frequently than not and requires a lot of knowledge about the system and the software to do successfully, usually. Trying to get closer and closer to continuous integration/continuous deployment but it’s like eating an elephant, with tablespoon sized two week sprints.