How do I instill good software development practices?
June 20, 2019 4:53 PM
This is not the first time this has happened, but I am at a smaller software company that has a "hero" complex with developers. They believe agile is too hard and a waste of time and that just working through things is the way to go. I've worked at very large companies you've probably heard of and found things like sprint planning, backlog grooming, etc. aren't a waste of time and make everyone happy in the end. What's the best, most effective way to convince them to adopt agile concepts?
I'm not very process heavy, but I found that doing things like establishing things like story points, or hours, and velocity helps projects get completed. Defining the definition of done is important so everyone knows what to expect when done, and if it changes, that is great but needs to be accounted for. In short I'm in an organization that sees all this project management as overhead that is not needed. The most successful projects I've been on actually have had these processes in place, and yes there might be time wasted in the long run the benefit is that everyone knows what is committed to and what is to be expected. Not to turn this into a therapy session I feel as if I was hired because I worked on very large projects at very large companies and am the "expert" except when it is not convenient for me to be the expert.
This is not the first time I've encountered this and it seems to be a small company sort of problem, mainly because a lot of people at small companies just don't know the benefits of not working 12 hour days. Is there anyway politically or otherwise to approach this and let them know that even if they are not burning out employees it is not effective in delivering a successful product?
If this was the first time I've encountered this I would assume it was a one-off thing but I feel as if this is a growing pain small companies go through. I'd like to help them get over the hump without the argument that the budget does not allow for estimating items when the real answer is that you can't afford not to, which sounds like a cliche.
Again, not to repeat myself but I do understand how things feel slow with solid processes in place, but you absolutely know that things will be delivered on schedule. A lot of this is training the product owners you can't pivot in the middle because something suddenly seems like a priority, I just have yet to figure out how you go from work all the time and deliver an inferior product to work sane hours and deliver something expected. Companies obviously must go through this process to a certain extent, since I see such a contrast in small startup style companies and large software agencies. How do I politically navigate this, or does this just happen organically?
I'm not very process heavy, but I found that doing things like establishing things like story points, or hours, and velocity helps projects get completed. Defining the definition of done is important so everyone knows what to expect when done, and if it changes, that is great but needs to be accounted for. In short I'm in an organization that sees all this project management as overhead that is not needed. The most successful projects I've been on actually have had these processes in place, and yes there might be time wasted in the long run the benefit is that everyone knows what is committed to and what is to be expected. Not to turn this into a therapy session I feel as if I was hired because I worked on very large projects at very large companies and am the "expert" except when it is not convenient for me to be the expert.
This is not the first time I've encountered this and it seems to be a small company sort of problem, mainly because a lot of people at small companies just don't know the benefits of not working 12 hour days. Is there anyway politically or otherwise to approach this and let them know that even if they are not burning out employees it is not effective in delivering a successful product?
If this was the first time I've encountered this I would assume it was a one-off thing but I feel as if this is a growing pain small companies go through. I'd like to help them get over the hump without the argument that the budget does not allow for estimating items when the real answer is that you can't afford not to, which sounds like a cliche.
Again, not to repeat myself but I do understand how things feel slow with solid processes in place, but you absolutely know that things will be delivered on schedule. A lot of this is training the product owners you can't pivot in the middle because something suddenly seems like a priority, I just have yet to figure out how you go from work all the time and deliver an inferior product to work sane hours and deliver something expected. Companies obviously must go through this process to a certain extent, since I see such a contrast in small startup style companies and large software agencies. How do I politically navigate this, or does this just happen organically?
In situations similar to this I’ve found it helps a lot to break things down into baby steps and also to not call things by their names. Like, “hey, could we make a list of all the features we want to implement, and assign/prioritize them every couple of weeks?” Then it’s “oh I got assigned too much for this week; maybe next week we can estimate whether each feature is small, medium, or large, and budget each person accordingly?” and then before you know it your frog is in a pot of boiling backlog with story points. Ideally everyone notices the benefits along the way and it becomes an ingrained habit that gets enforced by PMs.
But it’s also been my experience that a place that rewards “heroes” and “rock stars” doesn’t do well implementing any processes, because they’re never held accountable for failing to follow them. The only way out of that, if they do not report to you, is to leave, unfortunately.
posted by olinerd at 5:16 PM on June 20, 2019
But it’s also been my experience that a place that rewards “heroes” and “rock stars” doesn’t do well implementing any processes, because they’re never held accountable for failing to follow them. The only way out of that, if they do not report to you, is to leave, unfortunately.
posted by olinerd at 5:16 PM on June 20, 2019
One of the problems with agile/six sigma/lean and related frameworks it that coming into it cold, it all sounds like total BS. They also carry the stink of Big Company Disease.
Are there ways to sell the methodology without sounding like you are selling it?
posted by Dr. Twist at 5:18 PM on June 20, 2019
Are there ways to sell the methodology without sounding like you are selling it?
posted by Dr. Twist at 5:18 PM on June 20, 2019
Most things selling agile are selling it to people who are fleeing waterfall. You need to sell it from a lack of process. The Phoenix Project is probably the canonical book from this point of view. I think the thing that has helped me sell agile best is leading with “we are going to use just enough process and not just adopt someone else’s process” and “we are trying this for three months, then checking back in.”
posted by advicepig at 5:25 PM on June 20, 2019
posted by advicepig at 5:25 PM on June 20, 2019
What will they do? Ask the team what they think the problems are, and then help them to make the changes that are necessary to address those issues. It is unwise to try to change everything all at once, especially in the face of an unwilling team. Make small changes as needed, and only do what your team can get behind.
If they feel successful and if they trust you, you will be able to get to somewhere you want to be, though it may not be where you think you want to go now, if that makes any sense.
Seconding “The Phoenix Project”.
posted by chrchr at 6:08 PM on June 20, 2019
If they feel successful and if they trust you, you will be able to get to somewhere you want to be, though it may not be where you think you want to go now, if that makes any sense.
Seconding “The Phoenix Project”.
posted by chrchr at 6:08 PM on June 20, 2019
In my 40+ years experience the greatest obstacle is knowledge and communication.
Multi-tier architecture but people don't understand the implications of that when it comes to rolling out changes? Doesn't matter what system you use, ignorance is like a laser that will burn through it.
Incorrect written specifications by new hires who are poorly managed? Doesn't matter your system, you will constantly be playing catch-up due to "signed-off" specs that are wrong.
For that matter, "rock stars" who delegate to others by example (i.e., no formal specs, just napkin diagrams), then the rock stars become unavailable (travel, meetings, conference calls) to provide clarifications or answers as the project progresses, so the developers can't make consistent progress.
Put all the above together and for good measure provide a PMO who doesn't understand why nothing gets done, or doesn't have the political power to get any of it corrected.
So I guess what I'm saying is that "all things being equal" I think modern processes are great (as is going home on time), but the worst thing I have seen is people trying to cling to a process to save them from poor hiring and training practices, "silo" political mentalities and rotten specification quality. Take all that out of the mix and the kind of rational non-jargon conversation that olinerd described above should convince people of the benefits.
posted by forthright at 6:43 PM on June 20, 2019
Multi-tier architecture but people don't understand the implications of that when it comes to rolling out changes? Doesn't matter what system you use, ignorance is like a laser that will burn through it.
Incorrect written specifications by new hires who are poorly managed? Doesn't matter your system, you will constantly be playing catch-up due to "signed-off" specs that are wrong.
For that matter, "rock stars" who delegate to others by example (i.e., no formal specs, just napkin diagrams), then the rock stars become unavailable (travel, meetings, conference calls) to provide clarifications or answers as the project progresses, so the developers can't make consistent progress.
Put all the above together and for good measure provide a PMO who doesn't understand why nothing gets done, or doesn't have the political power to get any of it corrected.
So I guess what I'm saying is that "all things being equal" I think modern processes are great (as is going home on time), but the worst thing I have seen is people trying to cling to a process to save them from poor hiring and training practices, "silo" political mentalities and rotten specification quality. Take all that out of the mix and the kind of rational non-jargon conversation that olinerd described above should convince people of the benefits.
posted by forthright at 6:43 PM on June 20, 2019
Maybe kanban is a lighter process agile approach that would be easier to pitch? If, that is, it makes sense for your company's problem space.
posted by kokaku at 7:30 PM on June 20, 2019
posted by kokaku at 7:30 PM on June 20, 2019
As far as pitching, find a small project to use as a trial and then do a thorough post-project review highlighting where process helped, how it was received, where there were problems, etc.
posted by kokaku at 7:31 PM on June 20, 2019
posted by kokaku at 7:31 PM on June 20, 2019
I'm not very process heavy, but I found that doing things like establishing things like story points, or hours, and velocity helps projects get completed.
I think olinerd and Dr. Twist have it right. If this is the language you're using to sell these processes to your new coworkers, I'm not surprised they're not buying. I stepped away from team software development while agile was still hitting its stride, and I think you've underestimated how off-putting the very language of it can sound to someone not familiar with it.
posted by jimw at 7:45 PM on June 20, 2019
I think olinerd and Dr. Twist have it right. If this is the language you're using to sell these processes to your new coworkers, I'm not surprised they're not buying. I stepped away from team software development while agile was still hitting its stride, and I think you've underestimated how off-putting the very language of it can sound to someone not familiar with it.
posted by jimw at 7:45 PM on June 20, 2019
Do you have any power? Influence? Can you lead a small pilot team with new practices and metrics for results? If you’re just a cog, complaining, you’ll get nowhere and lose any capital you had. At least find other cogs who’ve been there to be allies. Get leaders to be allies, you do the work under their capital and they get the kudos. Or get a new job. Sorry to be so cynical. 20 years in the software industry.
posted by matildaben at 7:58 PM on June 20, 2019
posted by matildaben at 7:58 PM on June 20, 2019
olinerd wrote:
a place that rewards “heroes” and “rock stars” doesn’t do well implementing any processes
Agreed. And it’s not too surprising: “heroes” and “rock stars” like being “heroes” and “rock stars”. They’re not going to like anything that could unseat them.
I’m arguably biased because getting caught in the middle of a really awful attempt at agile was a large part of why I left the industry. I come from the Richard Stallman / Fred Brooks era of software development, where programming was a creative, challenging, and even enjoyable task. Long hours and all-nighters were like proudly worn battle scars. Anybody could be a “hero” if they successfully took on a hard task. Agile (IMHO) is an effort to commoditize programming and turn it into something like factory work.
Personally, I’m not convinced that the “rock star” model is all bad. It’s not all good, either. But in some situations it can be productive. And from a mgmt / leadership perspective, stroking a huge programmer ego is an easy and effective way to make things happen.
posted by doctor tough love at 9:00 PM on June 20, 2019
a place that rewards “heroes” and “rock stars” doesn’t do well implementing any processes
Agreed. And it’s not too surprising: “heroes” and “rock stars” like being “heroes” and “rock stars”. They’re not going to like anything that could unseat them.
I’m arguably biased because getting caught in the middle of a really awful attempt at agile was a large part of why I left the industry. I come from the Richard Stallman / Fred Brooks era of software development, where programming was a creative, challenging, and even enjoyable task. Long hours and all-nighters were like proudly worn battle scars. Anybody could be a “hero” if they successfully took on a hard task. Agile (IMHO) is an effort to commoditize programming and turn it into something like factory work.
Personally, I’m not convinced that the “rock star” model is all bad. It’s not all good, either. But in some situations it can be productive. And from a mgmt / leadership perspective, stroking a huge programmer ego is an easy and effective way to make things happen.
posted by doctor tough love at 9:00 PM on June 20, 2019
I think you've underestimated how off-putting the very language of it can sound to someone not familiar with it.
Couldn’t agree more. Source: like process and predictability; will never, ever, ever, ever use the Fibonacci sequence to estimate story points. Oh lord, just no
posted by sevensnowflakes at 9:09 PM on June 20, 2019
Couldn’t agree more. Source: like process and predictability; will never, ever, ever, ever use the Fibonacci sequence to estimate story points. Oh lord, just no
posted by sevensnowflakes at 9:09 PM on June 20, 2019
It's typical for software development teams to sort of reinvent the wheel in each case when moving from an ad hoc process to any kind of managed / shared model of what's going on, and in some sense that's fine: change is easier if it's gradual and makes sense to people step by step. Conceptually, it's actually pretty similar to agreeing to a definition of done, just on a larger scale. You know you'll arrive at a shared picture of how development works, but it's going to be tailored to local needs and perspectives in order to achieve consensus.
You're in the position of knowing what a good process could look like, and maybe you can assess what's most dire and/or most easily changed in your current environment to pick your first target. If it were me, I'd wonder whether bi-weekly demos would be a good starting point, because show & tell is a fairly natural activity, management probably likes seeing regular progress, developers need to know how other work has turned out so they can plan to integrate with it, it's a good opportunity to praise the team's work, and that praise may reinforce good development practices (e.g. thinking about how to break work up into demoable chunks).
But maybe you already have that or maybe your issues lie elsewhere. I just mean to illustrate choosing one thing you've seen work elsewhere, making a locally relevant case for it, and thinking about how it eventually implies other common parts of agile processes. For example, if you have demos every other week, maybe the next step is making notes about what new integration work you've discovered in it (a first step in defining a backlog) or talking in general about what happened that two weeks (a first step toward retrospectives) and so on until you have a recognizably normal process but one people have settled into because it just sort of made sense.
posted by Wobbuffet at 10:21 PM on June 20, 2019
You're in the position of knowing what a good process could look like, and maybe you can assess what's most dire and/or most easily changed in your current environment to pick your first target. If it were me, I'd wonder whether bi-weekly demos would be a good starting point, because show & tell is a fairly natural activity, management probably likes seeing regular progress, developers need to know how other work has turned out so they can plan to integrate with it, it's a good opportunity to praise the team's work, and that praise may reinforce good development practices (e.g. thinking about how to break work up into demoable chunks).
But maybe you already have that or maybe your issues lie elsewhere. I just mean to illustrate choosing one thing you've seen work elsewhere, making a locally relevant case for it, and thinking about how it eventually implies other common parts of agile processes. For example, if you have demos every other week, maybe the next step is making notes about what new integration work you've discovered in it (a first step in defining a backlog) or talking in general about what happened that two weeks (a first step toward retrospectives) and so on until you have a recognizably normal process but one people have settled into because it just sort of made sense.
posted by Wobbuffet at 10:21 PM on June 20, 2019
It's not clear to me at what position you've come into this company as. Are you a manager, or a senior member of the rank and file? Are you in engineering or product?
If you are engineering management, I'll say that this is not something to spring on your team before you've established a solid rapport with them. Absolutely do not book a meeting from 1-6pm on Friday with an Expert Trainer who points at people, puts them on the spot (is this five points or eight? five or eight?), and makes one of your teammates run out of the room with a panic attack.
Less abstractly: I joined a team that was not using 'agile'. Then all the original management left after we launched, and we got a new guy. New guy and my first 1:1 was mostly him talking, and I didn't come away with a feeling of trust. A few weeks later, this epic 1-6pm meeting on a Friday where my teammate ran out of the room with a panic attack. A few weeks later, I was outta there, and so was she. I went onto a team that does not do agile, and continue to be a little leery of it.
I think the key is to build rapport (i.e. people have to like you first; they cannot see you as the new guy who wants to shake things up, for impact!), socialize the idea, get a core group who are using it pretty painlessly, and make it opt-in.
posted by batter_my_heart at 10:25 PM on June 20, 2019
If you are engineering management, I'll say that this is not something to spring on your team before you've established a solid rapport with them. Absolutely do not book a meeting from 1-6pm on Friday with an Expert Trainer who points at people, puts them on the spot (is this five points or eight? five or eight?), and makes one of your teammates run out of the room with a panic attack.
Less abstractly: I joined a team that was not using 'agile'. Then all the original management left after we launched, and we got a new guy. New guy and my first 1:1 was mostly him talking, and I didn't come away with a feeling of trust. A few weeks later, this epic 1-6pm meeting on a Friday where my teammate ran out of the room with a panic attack. A few weeks later, I was outta there, and so was she. I went onto a team that does not do agile, and continue to be a little leery of it.
I think the key is to build rapport (i.e. people have to like you first; they cannot see you as the new guy who wants to shake things up, for impact!), socialize the idea, get a core group who are using it pretty painlessly, and make it opt-in.
posted by batter_my_heart at 10:25 PM on June 20, 2019
Ask if you can do it as an experiment and document it as a case study for the organization. Get a team for a project to try it, buy into it, and evangelize it with you. It's a better pitch when a team can describe their experiences and it doesn't just look like your personal hobbyhorse. It's also a good way for the org to dip their toe in.
"Rock Star" to me means you're told to do something at the very last minute and need to put a ton of work into making it happen on time. "Rock Star" is a word you use when you're trying to convince someone you're taking advantage of that they're not a sucker. I personally find it almost as demeaning as the slice of pizza reward for two weeks overtime.
What you can't change is if short deadlines are constantly thrown over the wall. You don't have any choice but to hit the ground running. If that's always the case leave. Anyway, the garbage code will build up, no one will remember where the bodies are buried, and you'll be stuck with a junk product developers are scared to touch.
posted by xammerboy at 11:00 PM on June 20, 2019
"Rock Star" to me means you're told to do something at the very last minute and need to put a ton of work into making it happen on time. "Rock Star" is a word you use when you're trying to convince someone you're taking advantage of that they're not a sucker. I personally find it almost as demeaning as the slice of pizza reward for two weeks overtime.
What you can't change is if short deadlines are constantly thrown over the wall. You don't have any choice but to hit the ground running. If that's always the case leave. Anyway, the garbage code will build up, no one will remember where the bodies are buried, and you'll be stuck with a junk product developers are scared to touch.
posted by xammerboy at 11:00 PM on June 20, 2019
Agree with others who are asking what your role / influence is.
I believe there is value in you adopting the spirit of the process for your own work. Like, make a very simple xls of a prioritized backlog of your work, with your current estimated time to completion and how that maps to milestones. Have a very short meeting with your manager or team every week or two to ensure it's still valid, and that you're aligned on success criteria. Use it as a clear reference of communicating risk and status.
Track your own velocity, to use when you're being asked to overcommit.
posted by spandex at 12:47 AM on June 21, 2019
I believe there is value in you adopting the spirit of the process for your own work. Like, make a very simple xls of a prioritized backlog of your work, with your current estimated time to completion and how that maps to milestones. Have a very short meeting with your manager or team every week or two to ensure it's still valid, and that you're aligned on success criteria. Use it as a clear reference of communicating risk and status.
Track your own velocity, to use when you're being asked to overcommit.
posted by spandex at 12:47 AM on June 21, 2019
How do I politically navigate this, or does this just happen organically?
Carefully and slowly, picking off pain points that a story or breaking down detail will clearly (to all) improve the process. Avoid dogma, find examples that make sense to the entire organization. It's really hard to translate a huge blob of project plan into the new story structure, perhaps a tiger team for one distinct chunk. Teach the feeders, the business managers/VP's and their actual lieutenants, the folks with the specific problem details first, if the "stories" are not at the right detail how can the engineers make any sense of the process. How does the actual process actually work currently, does a doc get written correctly or does a scrap of an messily defined problem get sent over and one of the programmers gets on the phone to one key employee that actually grasps the details, that may be the person to start with...
posted by sammyo at 7:33 AM on June 21, 2019
Carefully and slowly, picking off pain points that a story or breaking down detail will clearly (to all) improve the process. Avoid dogma, find examples that make sense to the entire organization. It's really hard to translate a huge blob of project plan into the new story structure, perhaps a tiger team for one distinct chunk. Teach the feeders, the business managers/VP's and their actual lieutenants, the folks with the specific problem details first, if the "stories" are not at the right detail how can the engineers make any sense of the process. How does the actual process actually work currently, does a doc get written correctly or does a scrap of an messily defined problem get sent over and one of the programmers gets on the phone to one key employee that actually grasps the details, that may be the person to start with...
posted by sammyo at 7:33 AM on June 21, 2019
A lot of great suggestions in this thread. I'll share my experience as I've been in a situation comparable to what you've described in my last two positions: brought in as lead developer for a small team that didn't have much of a formal project management process. I guess I am lucky to have a pretty good sense of what a successful development process looks like. (It originally emerged out of a workshop we did years ago to introduce scrum at one company I was with and some really bad experiences with it.) In both cases, I succeeded in getting an agile scrum process established pretty quickly with developers who were happy to be part of it.
I may have had some advantages over your situation:
1. The teams were small with relatively inexperienced developers without a lot of ego. In the first instance, it was the developers who agitated to have my position created and filled.
2. Management was both supportive and largely hands-off. They came to appreciate the knock-on effects that more orderly software project management had for the organization.
3. I was being hired into a lead developer role and discussions of development practices and agile scrum had been key themes in my interviews. If you're not designated to lead this team in some fashion, all of this will be much trickier to navigate.
What I did to get started in both cases was to meet individually with the developers on the team and ask them a couple questions: what's frustrating you? What would you change about the way things are currently being done? I also asked them about their opinions and experience with agile scrum? (In some cases, this had already been covered in part in interviews they participated in. Still, we go deeper.)
As this thread shows, a lot of developers are justifiably skeptical about agile or formal process more generally because they've seen it poorly practiced or mismanaged. In talking with my new co-workers, I share my view of the pros and cons of agile scrum. Be honest with them: there are tradeoffs. One of them being, you may no longer get to be a rock star. But maybe you turn into more of a folk legend. :)
I make the case to them that agile is in their interests. Are they being constantly interrupted by people with new tasks or projects? Do assignments drag on due to scope creep or a lack of specs? Are they constantly putting out fires because of poor planning or rushed code? I tell them I like scrum because, if we can get it going right, it will protect them from these things.
These meetings were crucial. In my case, they went pretty well. If they hadn't, I needed to be prepared to adjust. You make adjustments in any case. That's the point with agile, right?
After that, I scheduled a team meeting to outline a path forward and discuss how we transition their current work into stories and sprints.
As far as practices to get up and running with? I agree with the suggestions that it's best to start small and fill in the process as you go. I set up a Trello board with four columns: planning, backlog, current sprint, sprint completed. In that first team meeting, I introduce it and we work together to create cards (i.e. stories) for what they are currently working on. I explain the concept of a user story, that even though it sounds kind of corny, since it focuses on a user need, it's a great way to make sure you're working on stuff that matters. We include a checklist of requirements or specs on each card. And we go from there.
posted by bunbury at 9:01 AM on June 22, 2019
I may have had some advantages over your situation:
1. The teams were small with relatively inexperienced developers without a lot of ego. In the first instance, it was the developers who agitated to have my position created and filled.
2. Management was both supportive and largely hands-off. They came to appreciate the knock-on effects that more orderly software project management had for the organization.
3. I was being hired into a lead developer role and discussions of development practices and agile scrum had been key themes in my interviews. If you're not designated to lead this team in some fashion, all of this will be much trickier to navigate.
What I did to get started in both cases was to meet individually with the developers on the team and ask them a couple questions: what's frustrating you? What would you change about the way things are currently being done? I also asked them about their opinions and experience with agile scrum? (In some cases, this had already been covered in part in interviews they participated in. Still, we go deeper.)
As this thread shows, a lot of developers are justifiably skeptical about agile or formal process more generally because they've seen it poorly practiced or mismanaged. In talking with my new co-workers, I share my view of the pros and cons of agile scrum. Be honest with them: there are tradeoffs. One of them being, you may no longer get to be a rock star. But maybe you turn into more of a folk legend. :)
I make the case to them that agile is in their interests. Are they being constantly interrupted by people with new tasks or projects? Do assignments drag on due to scope creep or a lack of specs? Are they constantly putting out fires because of poor planning or rushed code? I tell them I like scrum because, if we can get it going right, it will protect them from these things.
These meetings were crucial. In my case, they went pretty well. If they hadn't, I needed to be prepared to adjust. You make adjustments in any case. That's the point with agile, right?
After that, I scheduled a team meeting to outline a path forward and discuss how we transition their current work into stories and sprints.
As far as practices to get up and running with? I agree with the suggestions that it's best to start small and fill in the process as you go. I set up a Trello board with four columns: planning, backlog, current sprint, sprint completed. In that first team meeting, I introduce it and we work together to create cards (i.e. stories) for what they are currently working on. I explain the concept of a user story, that even though it sounds kind of corny, since it focuses on a user need, it's a great way to make sure you're working on stuff that matters. We include a checklist of requirements or specs on each card. And we go from there.
posted by bunbury at 9:01 AM on June 22, 2019
How do I politically navigate this, or does this just happen organically?
...track... your own work...
So - when I was first introduced to Agile in the workplace (I had read about it, but was skeptical), it was by a consultant who "ate his own dogfood" - he didn't try to convince us that this was the new mantra, he did it quietly for his own deliverables. Now - he was happy to educate and mentor, when people asked him what his secret was... (because he met his targets, was not overworked and very happy in general)
Oh - and I cannot recommend "The Phoenix Project" enough... I has gifted it at a conference by one of the authors, then proceeded to head to dinner and a party, got back to the hotel room at about 10:45pm, decided to take a peek and was up reading it until 5am... It was "my life" at many points of my career. (And BTW, for those who haven't read it - Kanban is key)
Since then, I have purchased at least 3 more copies - because I give it out to managers/leadership that I respect and hope they can learn from it.
posted by jkaczor at 7:31 AM on June 26, 2019
...track... your own work...
So - when I was first introduced to Agile in the workplace (I had read about it, but was skeptical), it was by a consultant who "ate his own dogfood" - he didn't try to convince us that this was the new mantra, he did it quietly for his own deliverables. Now - he was happy to educate and mentor, when people asked him what his secret was... (because he met his targets, was not overworked and very happy in general)
Oh - and I cannot recommend "The Phoenix Project" enough... I has gifted it at a conference by one of the authors, then proceeded to head to dinner and a party, got back to the hotel room at about 10:45pm, decided to take a peek and was up reading it until 5am... It was "my life" at many points of my career. (And BTW, for those who haven't read it - Kanban is key)
Since then, I have purchased at least 3 more copies - because I give it out to managers/leadership that I respect and hope they can learn from it.
posted by jkaczor at 7:31 AM on June 26, 2019
Well for follow up, I was let go. I did not force agile or any methodology. My goal was predictability. I purposely left out my role because I was trying to be somewhat anonymous but I was the lead developer/architect. I was going for the soft approach as mentioned above. I did a rudimentary project plan with dates and that was not liked because the client in question would randomly ask for things and I was told that was the way the project worked.
In any case I guess even if you kind of accept things are not working well and want to make small changes it will still not work out.
posted by geoff. at 12:30 PM on June 27, 2019
In any case I guess even if you kind of accept things are not working well and want to make small changes it will still not work out.
posted by geoff. at 12:30 PM on June 27, 2019
Man that sucks - well, you were definitely in the right role to lead a methodology change. But some teams and organizations will simply never change until management (i.e. "oooh, I drank this fancy kool-aid and/or succumbed to CxO envy while on the golf course with my pals") or legal (i.e. "something bad happened") forces it upon them.
The stupid thing about that is "client randomly asking for things" is well handled by Kanban or an Agile/SCRUM "backlog".
I have seen one small company where the owner wanted a custom system, he would constantly ask for changes - and the developer he was paying (full time contract) would always accommodate... It was 2.5 years of this and never went into production (should have been finished in 6 months), in the end the developer quit because he wanted to "ship" something.
Well - good luck - send me a MeMail, I know people who are always looking for good people remote, depending on your skillset/tech. background.
posted by jkaczor at 1:37 PM on June 27, 2019
The stupid thing about that is "client randomly asking for things" is well handled by Kanban or an Agile/SCRUM "backlog".
I have seen one small company where the owner wanted a custom system, he would constantly ask for changes - and the developer he was paying (full time contract) would always accommodate... It was 2.5 years of this and never went into production (should have been finished in 6 months), in the end the developer quit because he wanted to "ship" something.
Well - good luck - send me a MeMail, I know people who are always looking for good people remote, depending on your skillset/tech. background.
posted by jkaczor at 1:37 PM on June 27, 2019
Yeah, clients asking for random stuff and disrupting the project plan is, like, the classic scenario where agile approaches beat traditional product management.
Sounds like somebody with political clout just didn't want to change. Their loss.
posted by tobascodagama at 1:47 PM on June 27, 2019
Sounds like somebody with political clout just didn't want to change. Their loss.
posted by tobascodagama at 1:47 PM on June 27, 2019
Source: like process and predictability; will never, ever, ever, ever use the Fibonacci sequence to estimate story points.
I agree, and I've seen even more absurd things like I think it was a dog, a chicken and maybe some sort of fruit. I know people who swear by abstracting this but in my mind I have "x" about of hours for this week and if you're abstracting this I'm just going to do the conversion in my head.
That said, if using 1, 3, 5, 7 for story points is the only disadvantage, that's not a huge disadvantage.
I will say I think people are really bad at project management in general (it is hard when done well, and unfortunately can be sort of half assed), and 1, 3, 5, 7 builds in things like resources are not 80 hours every two weeks, but maybe 50 hours + unexpected things and bugs. Everyone would agree to that when you tell them but if you stick to those actual numbers they don't always do the extra step of knowing that you are going to spend time not working on the task and the abstraction can help with that when someone comes in and demands why resource x is not working a full 80 hours and you're like well even if they were the standups alone are 5 hours of that, even if they literally did nothing else.
posted by geoff. at 2:09 PM on July 1, 2019
I agree, and I've seen even more absurd things like I think it was a dog, a chicken and maybe some sort of fruit. I know people who swear by abstracting this but in my mind I have "x" about of hours for this week and if you're abstracting this I'm just going to do the conversion in my head.
That said, if using 1, 3, 5, 7 for story points is the only disadvantage, that's not a huge disadvantage.
I will say I think people are really bad at project management in general (it is hard when done well, and unfortunately can be sort of half assed), and 1, 3, 5, 7 builds in things like resources are not 80 hours every two weeks, but maybe 50 hours + unexpected things and bugs. Everyone would agree to that when you tell them but if you stick to those actual numbers they don't always do the extra step of knowing that you are going to spend time not working on the task and the abstraction can help with that when someone comes in and demands why resource x is not working a full 80 hours and you're like well even if they were the standups alone are 5 hours of that, even if they literally did nothing else.
posted by geoff. at 2:09 PM on July 1, 2019
This thread is closed to new comments.
Also, it takes time for that predictability to develop, as the team dials in its story estimation and working velocity, so everyone needs to be patient as you work that out.
The main vibe I get from your question is that your company is burning out people by asking them to do too much. A new development methodology is not really the solution for that.
posted by Sauce Trough at 5:09 PM on June 20, 2019